
 
Department of Technology Management and Economics 
CHALMERS TEKNISKA HÖGSKOLA 
Göteborg, Sweden 2019 

 
Toward a framework for assessing 
meaningful differences between 
blockchain platforms 
Bachelors Thesis in Industrial Engineering and Management 
 

JESPER ALM 
JOHN LINDBLAD 
JONAS MEDDEB 
PHILIP NORD 
KRISTOFFER SÖDERBERG 
JAKOB WALL 


The Authors grants to Chalmers University of Technology and University of Gothenburg the 

non-exclusive right to publish the Work electronically and in a non-commercial purpose make 

it accessible on the Internet. The Authors warrants that he/she is the author to the Work, and 

warrants that the Work does not contain text, pictures or other material that violates 

copyright law. The Authors shall, when transferring the rights of the Work to a third party 

(for example a publisher or a company), acknowledge the third party about this agreement. If 

the Author has signed a copyright agreement with a third party regarding the Work, the 

Author warrants hereby that he/she has obtained any necessary permission from this third 

party to let Chalmers University of Technology and University of Gothenburg store the Work 

electronically and make it accessible on the Internet. 

 
Toward a framework for assessing meaningful differences between blockchain platforms 

 
JESPER ALM 

JOHN LINDBLAD 

JONAS MEDDEB 

PHILIP NORD 

KRISTOFFER SÖDERBERG 

JAKOB WALL 

 
© JESPER ALM, 2019. 

© JOHN LINDBLAD, 2019. 

© JONAS MEDDEB, 2019. 

© PHILIP NORD, 2019. 

© KRISTOFFER SÖDERBERG, 2019. 

© JAKOB WALL, 2019. 

 
Supervisor: Peter Altmann 

Examiner: Erik Bohlin 

Department of Technology Management and Economics 

Chalmers University of Technology 

SE-412 96 Gothenburg 

Sweden 

Telephone + 46 (0)31-772 1000 

 
Cover: 

Photo by Natalia Y on Unsplash 

 
Department of Technology Management and Economics 

Gothenburg, Sweden 2010 


Abstract

Blockchain technology has gained public interest as the technology behind cryptocur-
rencies. However, there is a potential for the technology to be applied in additional
contexts. One way to implement a blockchain solution is through use of a blockchain
platform. There are today many different platforms to choose from. Unfortunately,
blockchain platforms differ in the way that they operate and function. There is a lack of
frameworks for stakeholders to compare different blockchain platforms. The purpose
of this study is to provide a framework for comparing different blockchain platforms.
Further, the purpose is also to use the framework to identify meaningful differences
when developing a ROSCA application.

This study was conducted by an initial literature review of blockchain technology and
blockchain platforms to identify interesting properties. Three platforms, Ethereum,
Hyperledger Fabric, and Neo, were thoroughly examined. A ROSCA application
was developed on Ethereum, identified platform properties were evaluated, and finally
meaningful properties for the ROSCA application development were determined.

Thirteen platform properties were found and used as the structure for the platform
evaluation. Information about the three platforms was then structured to enable a jux-
taposition with each of them. The development of a ROSCA application showed that
important properties for a ROSCA application are trust, privacy and access, handling
payments, cost of development, and developer community.

This study form a foundation for further research about how to compare blockchain
platforms. The selection of blockchain platform properties can be used as a framework
to either evaluate blockchain platforms or in a comparison to other future frameworks.
The development of a ROSCA application showed meaningful differences for devel-
opment of that certain type of application. However, to get a more nuanced view on
meaningful properties for different applications, further research, including develop-
ment of other applications, as well as on other platforms, is crucial.

Keywords: blockchain, blockchain technology, blockchain platform, Ethereum,
Hyperledger Fabric, Neo, ROSCA, framework, decentralized application


Sammanfattning

Blockkedjetekniken har fått ökat allmänintresse genom sin roll som den grundläggande
tekniken bakom kryptovalutor. Det finns potential för att tekniken också kan skapa
nytta i andra kontexter. Ett sätt att implementera en blockkedjelösning är att använda
en blockkedjeplattform och idag finns många olika plattformar att välja mellan. Dessa
skiljer sig dock i sätten de fungerar på och det saknas sätt att jämföra olika blockkedje-
plattformar. Syftet med denna studie är att skapa ett ramverk för jämförelse mellan
olika blockkedjeplattformar. Vidare är syftet att använda ramverket för att identifiera
meningsfulla skillnader vid utvecklingen av en ROSCA-applikation.

Denna studie genomfördes genom en inledande litteraturstudie av blockkedjeteknik
och blockkedjeplattformar för att identifiera intressanta egenskaper för en jämförelse.
Tre plattformar, Ethereum, Hyperledger Fabric och Neo undersöktes grundligt. Senare
utvecklades en ROSCA-applikation på Ethereum och de identifierade egenskaperna
i hos plattformarna utvärderades, vilket slutligen resulterade i en redogörelse för de
meningsfulla egenskaperna för ROSCA-applikationen.

Tretton plattformsegenskaper hittades och användes som strukturen för plattforms-
utvärderingen. Information om de tre plattformarna strukturerades sedan för att möjlig-
göra en tabellstruktur vid jämförelse. Utvecklingen av en ROSCA-applikation visade
att viktiga egenskaper för en ROSCA-applikation är tillit, integritet och tillgång, betal-
ningshantering, utvecklingskostnader och community för utvecklare.

Denna studie utgör en grund för ytterligare forskning om hur jämförelse av block-
kedjeplattformar bör genomföras. Valet av meningsfulla egenskaper hos blockkedje-
plattformar kan användas som ett ramverk för att antingen utvärdera blockkedjeplatt-
formar, eller för jämförelse med framtida ramverk. Utvecklingen av en ROSCA-app-
likation hjälpte till med att identifiera meningsfulla skillnader för en ROSCA-applika-
tion. För att få en mer nyanserad och generell kartläggning av meningsfulla egenskaper
för olika applikationer krävs ytterligare utveckling och forskning, både av ytterligare
applikationer och på andra plattformar.


Contents

1 Introduction 1
1.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 3
2.1 Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Ledger and Data . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Decentralization . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4 Consensus mechanism . . . . . . . . . . . . . . . . . . . . . 6

2.2 Blockchain Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 System design choices . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 System performance . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Application development . . . . . . . . . . . . . . . . . . . . 15

2.3 Zamfir’s triangle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Rotating savings and credit association . . . . . . . . . . . . . . . . . 16

2.4.1 Introduction to ROSCAs . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3 Transactions of value . . . . . . . . . . . . . . . . . . . . . . 17
2.4.4 Joining the circle . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.5 Penalty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Method 19
3.1 Research design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Initial literature review . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Platform selection and examination . . . . . . . . . . . . . . 20
3.1.3 Development of ROSCA application . . . . . . . . . . . . . . 20
3.1.4 Concluding establishment of the final framework . . . . . . . 21

3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Method evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 Source evaluation . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Platform selection . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.3 Contribution of the development . . . . . . . . . . . . . . . . 23

i


3.3.4 Generalizability and usefulness . . . . . . . . . . . . . . . . 23

4 Platforms 24
4.1 Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 System design . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2 System performance . . . . . . . . . . . . . . . . . . . . . . 28
4.1.3 Platform ecosystem . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Neo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.1 System design . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.2 System performance . . . . . . . . . . . . . . . . . . . . . . 33
4.2.3 Platform ecosystem . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1 System design . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.2 System performance . . . . . . . . . . . . . . . . . . . . . . 38
4.3.3 Platform ecosystem . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Development 44
5.1 Selection of platform . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Development environment . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.1 Environment setup . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.2 Reference documentation . . . . . . . . . . . . . . . . . . . . 46

5.3 Application product . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.1 Contract data . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.2 Contract transactions . . . . . . . . . . . . . . . . . . . . . . 47

5.4 Obstacles encountered during development . . . . . . . . . . . . . . 48
5.4.1 Hiding data on a public blockchain . . . . . . . . . . . . . . 49
5.4.2 Operational cost analysis . . . . . . . . . . . . . . . . . . . . 50

6 Discussion 52
6.1 Comparison of platforms . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.1 Need of trust . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.2 Handling payments . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.3 Permission and identification . . . . . . . . . . . . . . . . . . 53
6.1.4 Transaction throughput and speed . . . . . . . . . . . . . . . 53
6.1.5 System stability . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.6 Development community . . . . . . . . . . . . . . . . . . . . 54
6.1.7 Cost of development . . . . . . . . . . . . . . . . . . . . . . 54

6.2 Establishment of framework . . . . . . . . . . . . . . . . . . . . . . 55
6.2.1 Meaningful differences . . . . . . . . . . . . . . . . . . . . . 55
6.2.2 Insignificant differences . . . . . . . . . . . . . . . . . . . . 56
6.2.3 Areas of usage . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.3 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1 Ecological sustainability . . . . . . . . . . . . . . . . . . . . 58
6.3.2 Social and economic sustainability . . . . . . . . . . . . . . . 59

ii


7 Conclusion 61
7.1 Directions for future research . . . . . . . . . . . . . . . . . . . . . . 62

References 63

Appendix A Platform examination questions 67

Appendix B ROSCA implementation 68

Appendix C Blind auction implementation 70

iii


Chapter 1

Introduction

The public interest in blockchain technology has grown rapidly in recent years. As the
key component for cryptocurrencies, the attention for blockchain technology increased
as the interest in cryptocurrency reached a peak at the beginning of 2018. Cryptocur-
rencies then had a total market cap of above 800 billion USD, with Bitcoin as the
flagship (CoinMarketCap, 2019). Besides acting as the foundation for cryptocurren-
cies, blockchain technology was assessed as one of the hottest emerging technologies
in Gartner’s hype cycle, both 2017 (Panetta, 2017), and 2018 (Panetta, 2018).

Interestingly, demonstrations of blockchain’s supposed benefits remain scant and there
is significant confusion around what a blockchain actually is and how it can and should
be used. For instance, definitions of blockchain technology diverge. Some highlight
its immutability, others its decentralization. This divergence causes confusion and pos-
sible misunderstanding of what blockchain technology is and how it differs from, and
relates to, existing technologies.

The lack of a common definition can be illustrated by the following three blockchain
definitions:

”A system in which a record of transactions made in bitcoin or another
cryptocurrency are maintained across several computers that are linked in
a peer-to-peer network.” (Oxford Dictionary, 2010)

”Blockchain is a shared, immutable ledger that facilitates the process of
recording transactions and tracking assets in a business network. An asset
can be tangible or intangible.” (IBM, 2019)

”The blockchain is a decentralized ledger of all transactions across a
peer-to-peer network.” (PwC, 2016)

The three above definitions have fundamental differences. The Oxford Dictionary de-
clares blockchain to be solely used to record cryptocurrency transactions while IBM
is slightly more general; describing blockchain technology to record transactions and
tracking assets in a business network. PwC is being less specific by suggesting that
the ledger simply holds all transactions. Other discrepancies of blockchain definitions
exists, not only between but also within industries (Jeffries, 2018).

Furthermore, it is not only the definition of a blockchain that might vary, but also the
blockchain implementation. Design parameters of a blockchain make the technology
modular and allow it to be optimized for different situations, resulting in a vast variety
in the way in which a blockchain might function. All of this contributes to challenges
when developers seek to leverage this emerging technology to realize their business
ideas.

1


Specifically, developers may build applications on various Blockchain platforms. These
platforms are established networks or frameworks for developers to use in order to
apply blockchain technology for their specific purpose. Many developers and other
kinds of stakeholders are examining the possibilities to develop blockchain applica-
tions. Thereby, they face one main challenge: there exists no framework for comparing
platforms to build the applications on. Without such a comparing framework, develop-
ers risk selecting a suboptimal blockchain platform for hosting their application.

The issues with lacking a framework for comparison have been examined in previ-
ous research. One example is a systematic review of current research on blockchain
technology that emphasizes the need for objective evaluation criteria for comparing
different blockchain solutions (Yli-Huumo, Ko, Choi, Park, & Smolander, 2016). The
versatility that characterizes blockchain platforms and the modularity of the technology
might be problematic when selecting a suitable platform for a specific application. One
possible way to facilitate this process would be to define a framework that articulates
differences between blockchain platforms to help developers analyze the platform’s
potential for their application.

1.1 Problem statement

There are many blockchain platforms providing blockchain solutions to developers
among different industries. However, there is a lack of frameworks for comparing
blockchain platforms. This problem has been identified and discussed for private
blockchain platforms (Tuan Anh Dinh et al., 2017) but not yet as a comprehensive
assessment for both private and public blockchain platforms.

Through a clearly articulated assessment framework, describing meaningful properties
and differences, developers are better able to select the appropriate blockchain plat-
form for a specific purpose. This makes it easier for anyone wanting to develop some
blockchain application to choose a platform that is a good fit for the application in
terms of matching the required attributes for the application with the properties of the
platform. An assessment framework also contributes to the common understanding of
blockchain technology by highlighting different key aspects of blockchain platforms
that either retain or evade certain system behavior.

1.2 Purpose

The purpose of this study is to provide application developers with a framework to com-
pare different blockchain platforms, by mapping differences between platforms, and
identifying which of them are meaningful through developing an application.

2


Chapter 2

Background

This chapter gives an introduction to theoretical concepts required to follow the work
presented in the rest of the report. It begins with an explanation of blockchain tech-
nology, focusing on how blockchain data structures can be used to store data in an
append-only ledger secured by cryptography. Followingly, distributed applications and
existing issues regarding decentralization of such applications are presented. Different
ways of how blockchain technology can help manage such issues, while at the same
time upholding the integrity of the ledger, are then covered. An introduction is there-
after given to blockchain networks as application platforms, and how these can enable
decentralized applications by hosting services defined using smart contracts. The chap-
ter ends with a description of the ROSCA system which was implemented in the study,
as an example of an decentralized application.

2.1 Blockchain Technology

Since there is no clear definition of what a blockchain is, this section focuses at a
selection of technologies present in blockchain platforms. These technologies are rele-
vant for understanding a blockchain as a type of distributed ledger, in which obtaining
consensus of the state is a decentralized process.

2.1.1 Ledger and Data

Traditionally, a ledger is a physical book used for keeping records, such as those related
to financial transactions or civil registrations. This fits the books’ physical nature since
records in ink can be appended easily, but are difficult to modify without leaving traces.
For a data structure, this is a property called append-only, meaning data can be written,
but neither deleted nor modified. A data structure with this property can be used as a
ledger, and updating the ledger state can then be done through recording data transac-
tions. A data transaction takes a valid state and modifies it in some way, rendering a
new valid state. When keeping record of all transactions, the current state of the ledger
can be calculated by processing these transactions in order. In blockchain systems,
such state model is referred to as unspent transaction output (UTXO) (Narayanan et
al., 2016). This, since the balance of an individual equals the unspent transaction out-
puts assignable to that individual when processing all conducted transactions. Cryp-
tocurrency payments are value transactions between different parties. In a ledger, these
value transactions can be recorded using data transactions modifying the state. This

3


type of data transaction deducts a given amount of currency from a sender, and adds
the same amount to a receiver (Narayanan et al., 2016).

When making digital ledgers, several issues arise in the lack of limitations of the digital
format. One of these is how digital files can be easily manipulated. A hash-linked list
is structured to work around this issue. The structure is based on linking together
ledgers through the use of cryptographic hashfunctions. These mathematical functions
can render a hash, which is a unique replicable fingerprint, of some kind of input data.
This allows a ledger to reference all transactions in another ledger by appending only
the hash of that ledger, as seen in Figure 2.1. By allowing ledgers to be broken down
into blocks, which use hash references to refer to previous blocks, a chain is created,
in which blocks can not be modified without modifying the hashes of the following
blocks (Narayanan et al., 2016). Since all data in the previous blocks affect the final
hash, integrity is kept through the aggravation of data manipulation.

Figure 2.1: Linked ledgers through hashing (Interpretation of figure from (Narayanan
et al., 2016))

As the state of the ledger can be calculated by processing its transactions, storing the
state explicitly is redundant. However, as the ledger grows, the amount of transactions
required to process to access the ledger state increases. Different variations of the data
structure use more or less redundancy to find a balance between utility and size. As
the shape of a data structure has an impact on the time complexity for searching and
modifying the data, the network can be optimized by developing and selecting efficient
data structures. One way to do this is by implementing a tree structure for the ledger,
such as a Merkle tree seen in Figure 2.2. While this is only one data structure, different
blockchain implementations may use different data structures, making different trade-
offs suited for their application. The Ethereum Modified Patricia Merkle Trie (Wood,
2014) is another example of how these data structures are modified and tailored for
specific usages.

2.1.2 Distribution

An important difference between physical and digital ledgers is the way digital ledgers
can be systematically distributed. The way distribution of data between computers in a
network is performed has evolved together with the growth of the internet. Distributed
applications consist of at least two communicating parties. In many applications, these
parties can be modelled as a client and a server (van Steen & Tanenbaum, 2018). The

4


Figure 2.2: A Merkle tree (David Göthberg, 2019)

client is the software which runs on the user computer, commonly referred to as an
application distributed to the user. The client provides the user interface of the appli-
cation, which lets the user interact and communicate with the server. The server is
the software which runs ”behind the scenes”, on a computer governed by the applica-
tion provider. It performs computations and responds to requests on data as a service.
The server also holds or communicates with the database, where application data is
kept.

2.1.3 Decentralization

Distributed applications let users interact with each other through the use of a third
party. This has opened up for new types of applications which have disrupted tradi-
tional industries (Zervas, Proserpio, & Byers, 2017). However, relying on a third party
to serve the application has some limitations. Decentralization removes the need of a
trusted third party, and has potential to enable transparent, trustless transactions of data
and value directly between parties (Wright & De Filippi, 2015).

Peer-to-peer networks are the first step towards decentralization, as they let peers con-
nect to a network of other peers directly. In these logical networks, peers may distribute
data between each other using their respective node in the network. The computer node
does not need to know every other node in the network, since nodes communicate us-
ing a common network protocol to efficiently offer the service to its peers. This pro-
tocol defines what rules nodes need to enforce in order to behave like a trusted node
(Narayanan et al., 2016).

Since a node in a network may be malicious, this protocol needs to handle byzantine
fault. Byzantine fault is defined in the byzantine generals problem as traitors able to
send incorrect information to the loyal generals, who need to agree on the same plan
(Lamport, Shostak, & Pease, 2002). If the loyal generals are able to decide upon the

5


same plan of action, while not knowing which of the other peers are traitors, their
tactics are byzantine fault tolerant. In a network where certain nodes are trusted, this
problem can be solved using digital signatures. It becomes more difficult however,
when the intent of the other generals is unknown. This allegory, explaining the problem
of trustless coordination, has greatly influenced research on consensus in distributed
systems (Lamport et al., 2002).

When different versions of the ledger state is created, either by time differences or
malicious nodes, a fork occurs. By implementing a byzantine fault tolerant consensus
protocol, the network assures that there is consensus about the state of the distributed
ledger. This, in a decentralized network, in which the integrity of the ledger state is
upheld without the need of a central authority. No such protocol is however tolerant
to hard forks, i.e. when some peers implement a different version of the consensus
protocol, incompatible with the previous one. Such scenario renders the ledgers in-
compatible and peers neglecting the other ledger as invalid, resulting in two separate
networks (Narayanan et al., 2016).

2.1.4 Consensus mechanism

In a decentralized network sharing a distributed ledger, the agreement on a the ledger
state is called consensus. Reaching consensus is a main challenge of decentralization
(Narayanan et al., 2016). In order to reach consensus, the network protocol incorpo-
rates a consensus mechanism consisting of a consensus model and a consensus algo-
rithm (Altmann, 2019). These can be implemented in various ways making the network
behave differently. When these two are combined in a sensible way the blockchain net-
work can be seen as byzantine fault tolerant.

Consensus model

The consensus model describes how the nodes allowed to create a new block on the
blockchain are selected (Altmann, 2019). The two selection procedures encountered
within this report are selection through randomization and selection through delegation.
A randomized selection process requires that the node that gets to create a new block
is selected in a randomized way. A selection through delegation on the other hand is
conducted by peers on the network electing other nodes, in which they trust, to be block
producers and to maintain the integrity of the network.

Consensus algorithm

The consensus algorithm describes how the validation of a new block is performed
(Altmann, 2019). There is a number of different consensus algorithms implemented
on different blockchain networks. These can be described as competitive based and
elective based (Altmann, 2019). The choice of algorithm impacts the finality of vali-
dation. Probabilistic finality on the other hand means that the transaction included in a

6


block on the chain can be reverted and that the risk of that transaction being reverted
is probabilistic.. The other case immediate finality does not allow a validated block to
become invalid (Vukolić, 2015).

Proof of work (PoW) is a commonly used competitive based algorithm for reaching
consensus on blockchain networks. The fundamental concept is that nodes can partici-
pate in the consensus process by performing computational puzzles to which there are
no quick solution. When a node completes a puzzle, it gets to create the next block
on the chain. Nodes validate the block by adding its hash in the next block extending
it. Since the chain is implemented as a linked list, only one chain can be the valid one
unless a fork has been made. This results in a racing game for the nodes to solve the
puzzle and thus being able to add a new block to the chain. Since computational power
is used for solving the puzzles, the protocol states that the chain with most work done
on it, meaning the longest one, is the valid one and that any other chain should be dis-
carded (Narayanan et al., 2016). A prominent drawback of the PoW algotithm is that
it is slow and can be very energy consuming (Wang, Zheng, Xie, Dai, & Chen, 2018).
The benefit is that it is the only objectively verifiable method known to reach consen-
sus (Altmann, 2019). Objectively verifiable means in this context that a node, with no
other knowledge except what is defined in the protocol, and that follows the consensus
algorithm, will come to the exact same conclusion as the rest of the network regard-
ing the current state. The opposite of objectively verifiable is subjectively verifiable.
Subjectively verifiable means in this context that different nodes in the network come
to different conclusions regarding the state when following the consensus algorithm.
This requires a large amount of social information, such as reputation or identity, to
participate in the consensus process (Vitalik Buterin, 2014).

Another competitive based consensus algorithm is proof of stake (PoS). Proof of stake
is based on the concept of acquiring a stake in the system to participate in the validation
of blocks. If a node agrees that a block is valid, it can validate this by placing a bet, or
stake, on that block. A benefit of this algorithm is that it is energy efficient. A drawback
is that it lacks objectiveness in its consensus procedure. (Wang et al., 2018).

As opposed to competitive based algorithms, the elective based algorithms require
some type of already established trust in the party elected to propose and validate
blocks. The benefit of elective based algorithms is that they offer higher performance
than competitive algorithms, with the drawback that they require a pre-established trust
in the validating party (Altmann, 2019).

Practical byzantine fault tolerance (pBFT) is an algorithm developed in 1999. Consen-
sus in a network implementing pBFT is maintained by a certain set of nodes, where
one is the leader node and the other are used as backup. When a request is sent on such
network, the leader node informs the backup nodes about the request, and then exe-
cutes the request. The leader node then informs the sender of the request result, who in
turn awaits the backup node’s response to come up with the same request result. The
integrity of such system is maintained through a majority vote that the request result is
correct. In order to guarantee integrity of the data in such a system it requires 3 f + 1
nodes to be able to tolerate f faults for the network to stay fault tolerant (Castro &
Liskov, 1999).

7


The delegated Byzantine fault tolerance (dBFT) is a consensus algorithm that operates
in the same way as pBFT but with a variation. In this set up nodes are part of consensus
through a system of proxy voting where the nodes, can vote for the validator they wish
to support. When the elected validators reach consensus around the transactions to be
included in a certain block, the block is generated and finality is achieved (Wang et al.,
2018).

2.2 Blockchain Platforms

Decentralized applications do not conform to the traditional client-server paradigm
since there is no central server. Instead, a decentralized application hosts its service
on a decentralized peer-to-peer network, letting clients interact with the application
through nodes on the network. Blockchain platforms support the development of new
types of decentralized applications (Buterin, 2019). This, through providing required
resources and infrastructure for execution, networking and data management. First in
this section, the application software that developers write for blockchain platforms,
commonly referred to as smart contracts, will be explained. Subsequently, parameters
that vary throughout different platforms’ designs will be presented. The design choices
give varying system performance, why the aspects of performance relevant for this
study will afterwards be covered. Ending the section is an explanation of some of the
resources helpful for developers on platforms.

2.2.1 Smart contracts

Application specific softwares executed by blockchain platforms are often referred to
as smart contracts. Because this software is distributed on the blockchain network,
consensus can be obtained on the code and how it should be executed. This uplifts the
software from being just code, to being a policy or a contract that peers can execute,
to enforce certain behaviour in how the state of the ledger should be modified. This
type of contract can represent the rules between two business parties. When a customer
and the owner of a vending machine interacts, the transaction is also automated. The
cost that the customer has to pay for a specific candy bar, and whether change is payed
out, are rules which are enforced by the machine. While a vending machine can act
incorrectly and it may be difficult for the customer to be justified for execution fault,
smart contracts are a way to make transactions predictable and transparent (Narayanan
et al., 2016).

2.2.2 System design choices

To understand the varying range of blockchain implementations existing, system design
choices, and their implications from different perspectives, need to be described. The
perspectives include which the participants are in the network, how they can interact

8


with the system, and what amount of privacy and access that is granted to different
participants. Further, important aspects regarding non-technical components, such as
incentive models and cost structures, are also presented in this section.

Participants

Every peer connected to a peer-to-peer network is running a node on the network.
However, a peer can behave in different ways, depending on in what way it intends
to interact with the network, and which functionality the network enables. Thus, the
explanation of what a node is needs to be broadened to fully understand how a peer can
connect and interact with the network.

A node is called a full node if it stores the entire blockchain (Satoshi Nakamoto, 2008).
If a full node creates and validates blocks on the network it can also be referred to as a
validating node (NEO Documentation, 2019). If a peer runs a full node on a network
implementing a PoW consensus algorithm, and creates blocks, the peer is also called a
miner. (Satoshi Nakamoto, 2008).

A peer who performs transactions on the network can be seen as an owner of an address
from which transactions can be sent and received (Satoshi Nakamoto, 2008). These
transactions can consist of cryptocurrencies, but also of some arbitrary data (Buterin,
2019). Owning an address and making transactions often require the use of a full node,
but it does not require that the address owner runs this full node by themselves. In order
for an owner of some address to make transactions, without the need to store the entire
blockchain, some blockchains implement a protocol called simplified payment verifi-
cation (SPV). Although, if they do not run a full node, they cannot participate in the
consensus mechanism (Satoshi Nakamoto, 2008). Since the structure and implementa-
tion varies among different blockchains, some blockchain networks enables the use of
what is called a light node. A light node is a node that only requires the storage of a
small part of the blockchain to verify transactions. Neither light nodes can participate
in the proof of work consensus algorithm (Buterin, 2019).

To ease the management of a user’s address a wallet is typically used. A wallet is a
software that keeps track of a peers cryptocurrency, manages all the details of their
public and private keys, and makes things convenient by providing the user with an
interface through which transactions can be made (Narayanan et al., 2016).

Interacting with the system

As already described in 2.1.1, all interaction with a decentralized network is based on
data transactions. In the context of blockchain platforms, such are commonly referred
to as simply transactions. A study of how participants can interact with a blockchain
network includes how transactions are conducted and what types of transactions there
are, as well as what different system operations a participant can get to execute through
transacting with the network.

9


Making transactions on a blockchain network requires computation. To compensate
the system, doing transactions may require a fee. This fee can be of different quantity
depending on what is specified in the protocol, what type of transaction it is, and how
much computational power it consumes. The transaction fee is in systems using PoW
given to the owner of the full node that created the block in which the transaction was
included (Buterin, 2019).

Two concepts regarding performing transactions related to blockchain networks are
on-chain and off-chain transactions. On-chain transactions constitute the transactions
made directly on the chain by broadcasting them to the network, whereupon full nodes
record them and add them to the blockchain. Off-chain transactions are instead en-
abled through private communication. They are not broadcasted immediately to the
blockchain, and relies completely on external recording to eventually be bookkeeped
on the chain (Gudgeon, Moreno-Sanchez, Roos, McCorry, & Gervais, 2019). Off-chain
transactions do not need to wait for all the nodes on the network to come to consensus
before getting the transaction verified, resulting in off-chain transactions being faster
than on-chain transactions. It can be rational to perform off-chain transactions as ap-
pose to on chain transactions as long as the transaction fees are lower than the ones
offered on-chain (Gudgeon et al., 2019).

Transactions are as mentioned the instrument for getting to execute operations on a
blockchain network. The operations available on blockchain platforms are often similar
to those present in traditional computing or database systems. Some networks, such as
Ethereum, constitutes their own virtual machines, i.e. systems serving similarly as
ordinary computers (Buterin, 2019). Examples of operations available in such virtual
machines are writing to storage, reading from storage, and doing simple computations
such as additions (Wood, 2014).

Access and privacy

Important issues are how anonymous a user is on a network, and how accessible to oth-
ers a user’s transactions are. This, because the participants interacting on a blockchain
network need to understand who can gain access to and read their data. Different de-
grees of privacy and access can be suitable for different purposes.

Peers connecting to a blockchain network can have a varying degree of anonymity
when identifying themselves. The anonymity in part reflects the degree of privacy
and depends on how the network is designed. When peers identify themselves on
the network, it is usually done through the use of digital signatures (Narayanan et al.,
2016). How the actual identification is performed can vary on different blockchain
networks. For instance, on some networks the user is only known through their public
key which represents the address from where they make transactions (Narayanan et
al., 2016)(Wood, 2014). Other networks enable the functionality of the peer choosing
whether to be anonymous or not (NEO Documentation, 2019).

The provided anonymity made possible by digital signatures is secure, but can be com-
promised if the user is careless. On some networks a user’s real identity could for

10


instance be compromised if a user often makes use of the same public key when mak-
ing transactions with cryptocurrency. The reason for this is that the network will store
all transactions ever made by that address and by using the same public key as identifier
the transactions could be linked to ones real identity by, for instance, analyzing ones
purchase patterns (Narayanan et al., 2016).

Linking to the introduction’s stated confusion concerning concepts in blockchain tech-
nology, some networks use the term private blockchain and public blockchain while
others use the term permissioned and permissionless blockchains. This has to do with
whether the access to the blockchain can be restricted or not. If a blockchain is public
or permissionless it is accessible by anyone, while a private or permissioned blockchain
is invitation based (Hyperledger, 2018). As will be shown in the platform section, some
blockchains implements a hybrid solution to the two.

User access

The hardware required to interact with a blockchain network varies depending on how a
peer intends to interact. If a user intends to run a full node, it only needs a computer that
has internet connection and disk storage to hold the entire blockchain (Narayanan et al.,
2016). If the intent is to run a light node less disk space is needed. If a peer intends to
perform mining, in theory, nothing more than what was stated for a full node is needed.
However, in practice, a miner will constantly need to upgrade its hardware for better
computational performance, since the computational puzzles constantly increases in
difficulty (Narayanan et al., 2016).

Incentive models

Since the blockchain network is upheld by nodes run by peers on the network, it would
stop working if nodes suddenly stopped participating in the consensus mechanism. The
way of giving peers an incentive to maintain this procedure is referred to as incentive
models. Understanding the incentive model on a blockchain network is important to
make a decision on whether to put in the effort to act as a validating node, as well as
whether to trust that the existing validating nodes are acting honestly or not.

When a miner finds a block, and this block is accepted onto the blockchain, in net-
works implementing PoW, the miner of that block is rewarded with some value unit,
commonly a network specific cryptocurrency. (Wood, 2014)(Satoshi Nakamoto, 2008).
Finding a new block is a probabilistic task and since it may take a long time before this
happens, the phenomenon of a mining pool has come in to place. A mining pool is
a group of miners forming a pool, in which all are attempting to find the next block,
and all have a designated recipient of the mining reward. This designated recipient is
called the pool manager, who will receive the entire reward when a block is found. The
pool manager then distributes the reward for finding the block depending on how much
work every miner has put into solving the puzzle. The pool manager can also take a
cut for himself for managing the mining pool. The use of a mining pool increases the

11


probability for a miner to get paid and the larger the mining pool the more attractive it
becomes, since it then gets more probable that the next created block will come from
this mining pool (Narayanan et al., 2016). This has resulted in the fact that most active
miners are connected to a mining pool, and that there are only a few different mining
pools doing the total mining performed on the largest proof of work blockchains. This
is an important aspect to understand when considering security aspects and networks’
degree of centralization (Etherscan, 2019).

The reward system in PoW networks are present in many networks with other consen-
sus mechanisms such as PoS and dBFT. Similarly, validating nodes are rewarded for
adding blocks to the chain, with an on chain transaction of some value unit. However,
in private blockchains, such as Hyperledger Fabric, transaction fees are not necessary.
This means validating nodes must be compensated either with off chain value transac-
tions or by gaining trust or reputation on the network (Hyperledger, 2018).

Hosting costs

In order for a miner to draw a conclusion on whether it is logical to act as a validating
node, or for a developer to decide to launch an application on the specific blockchain,
it is imperative to understand the underlying cost structure of that blockchain network.
The cost structure consists of everything that the user will have to pay for in order to
operate on the network and will, as shown, depend on what interaction the peer intends
to make. Whether the transactions are made on-chain or off-chain can have a strong
impact on the total expenditure of a users transactions. When considering a network’s
cost structure the overhead costs may also needs to be taken into account. For instance,
if a peer operates a validating node on a proof of work system then the overhead costs
would include buying mining equipment and paying for energy consumption (Satoshi
Nakamoto, 2008).

2.2.3 System performance

Aspects that describe the performance of a blockchain network have in this study been
divided into computing performance and system stability. Computing performance
is about a networks capacity to process transactions and operations, whereas system
stability is focused on the risk factors and reliability of the system.

Computing performance

In the aspect of computing performance, this study has mainly focused on transac-
tion throughput and how finality is achieved. Transaction throughput is measured in
transactions per seconds (TPS), which is the amount of transactions managed to be
performed on the blockchain per second. The limitation of the networks’ throughput
has to do with the fact that each block is hard coded to be of a certain size and therefore
it can only register a certain amount of transactions. Additionally, since transactions are

12


stored in blocks being created and added to the chain by nodes, the networks through-
put is also determined by the networks block time. Determining the networks’ TPS is
done by calculating the amount of transactions stored in a block divided by the block
creation time (Narayanan et al., 2016). The network throughput is essential in order
to understand how many concurrent transactions a system can handle. In this study
we will refer to a networks transaction speed as the inverse of the transaction through-
put.

A closely linked subject to transaction throughput is how finality is achieved. The
two types explained in this study are immediate finality and probabilistic finality. The
pBFT is an example of a consensus algorithm that offers immediate finality while the
PoW algorithm is an example of an algorithm that offers probabilistic finality (Vukolić,
2015). In networks providing probabilistic finality, users are usually recommended to
wait for a couple of block extensions before the transactions in a block are considered
finalized. The reason for this is that the probability of reverting the process diminishes
exponentially as more blocks extend the block holding the transactions to be considered
finalized (Satoshi Nakamoto, 2008). Since network latency increases with the number
of nodes in the network, the time to reach finality in a network is affected by both
network latency and the implemented algorithm for consensus.

In blockchain networks the block time can vary. As previously stated, the PoW al-
gorithm is the only objectively verifiable algorithm known, which in turn can offer
the network a high degree of decentralization if implemented in a sensible way. The
downside, as stated, is that it is slow in comparison to a, for instance, pBFT algorithm.
The reason that it’s slow is partly because it sets a difficulty in how long on average it
should take for a miner to find a new block. There are blockchains that uses 10 minutes
as block time and as we will see, others that have an average block time of around 10
seconds (Buterin, 2019). From the above calculation of transaction throughput it can
be concluded that the transaction throughput will increase with shorter block time, but
there are downsides with implementing a short block time, which will be discussed in
the following section.

System stability

System stability is in this study the aspect of how susceptible a blockchain is to sys-
tem disruption and its degree of centralization. A problem with implementing a PoW
algorithm that uses short block times is the increased probability of stale blocks and
forks. A stale block is a block that is found by a miner, deemed valid under protocol
but not accepted on the chain due to the fact that another miner also found a block and
it was that block that got accepted onto the long term chain. Since only one block is
included in the long term chain the other block and all resources allocated into min-
ing that block goes to waste. Shorter block times therefore increase waste, can deter
miners from mining, and thereby stop them from upholding the security of the system
(Buterin, 2019). Furthermore, latency in the network will make different nodes hear
about the broadcasted blocks at different times. The nodes will follow the protocol,
which in PoW blockchains means always extending the block that they heard about

13


first. This results in some nodes extending one of the blocks and other nodes extending
another, thereby increasing the risk of creating a fork on the chain. Additionally, short
block times in PoW algorithms also adds to the security concerns. One of those secu-
rity concerns is that larger mining pools will have an increased probability of getting
their blocks accepted. This, while smaller mining pools more frequently will see their
mined blocks orphaned, simply due to their small size. This can negatively impact the
networks degree of centralization. (Buterin, 2019).

Another issue that arise with competitive based consensus algorithms is the issue of a
51 percent attack. This is if an adversary controlling a large amount of the validating
nodes on the network was trying to compromise the system. There is nothing magical
about the 51 percent number, it only states that if someone controls a majority of the
validating nodes, then they could potentially compromise the system by subverting
consensus to their favour. This is possible since this single actor would then most
probably be the one to find and create most of the new blocks.

A possible way to compromise a POW system with a 51 percent attack is through a
double spend attempt. A double spend attempt is conducted by performing a cryp-
tocurrency transaction to someone and then revert that process by spending the same
cryptocurrency on a fork of the blockchain and make that the long term valid one by
adding blocks in a more frequent pace than the rest of the network. In theory, an ad-
versary could manage such attack with even less than majority control (Narayanan et
al., 2016). It has been shown that only 25 percent of the computational power can be
sufficient to forge blocks (Bach, Mihaljevic, & Zagar, 2018).

When a blockchain implements an elective based algorithm, it meets other security
issues. One of these are that, since an elective based consensus algorithm puts trust
in certain validating nodes, the system could be compromised by any of the validating
nodes if they would have such intentions. A system implementing an elective based
algorithm could be considered to have a high degree of centralization, since the network
is governed by a small amount of nodes (Altmann, 2019).

As blockchain networks evolve changes to the software may need to be made. When
the software gets updated there could be a situation where some nodes have updated
the new software but some have not. This would mean that some nodes would extend
blocks that other nodes would consider invalid and thereby ignore. This could result
in the nodes working on two different chains that both sides will consider to be the
longest and valid one. This causes a hard fork and the risk of this happening needs to
be considered when implementing changes to a blockchain network. (Narayanan et al.,
2016)

The above section represents a few different ways blockchain networks can be dis-
rupted. Another aspect when considering system disruption is the amount of nodes
that constitutes the network. Since it is proven that byzantine generals problem fails
when one third of the nodes are malicious or faulty and that the competitive based
algorithms are sensitive to 51 percent attacks proven to be possible with 25 percent
network control, the number of validating nodes on the network is an important aspect
to consider when estimating the networks risk of disruption.

14


2.2.4 Application development

Beyond the implementation of a certain blockchain with its properties, the viability
of an application platform also depends on how accessible the solution is to the de-
velopment team. The accessibility of an application platform benefits on how open the
platform is, as well as the size of the developer community, contributing to the available
tools, documentation, and development. This ties into how platforms which strive to-
wards open technology lowers development costs of applications because it encourages
contribution from the developer community (Holzer & Ondrus, 2011).

Open technology is also a key part of decentralized applications claiming to be trust-
less. This requires the network protocol and the code of the application to be open
source. The trust of a blockchain platform can be built on the basis of transparency,
relying on experts to review the systems for laymen to trust. Another way open source
allows the quality of the application to grow is when different parties can govern the
smart contract and client implementations. This opens up for several different clients
to compete of who gets to deliver a given service to the user (Vrba, 2018).

2.3 Zamfir’s triangle

There are models intended to better visualize certain aspects of different blockchain
platforms. Zamfir’s triangle is one, used in this study to justify choosing the three
different that were examined. Vlad Zamfir is one of Ethereum’s lead researchers and
thus exceedingly involved with blockchain platform development. Zamfir has proposed
a model, illustrated in Figure 2.3, for describing trade-offs in fault tolerant consensus
mechanisms for different blockchain platforms. This model visualizes that consensus
mechanisms are unable to achieve low latency finality, low overhead cost, and have
many validating nodes at the same time (Zamfir, 2017).

15


Figure 2.3: Zamfir’s triangle illustrating the fundamental trade-offs in fault tolerant
consensus mechanisms. (Interpretation of Zamfir’s original tweet (Zamfir, 2017))

The triangle is created so that corner A, as referenced in Figure 2.3, includes platforms
with both low latency finality and low overhead, but with few nodes. Corner B includes
platforms with low latency finality and many nodes, but high overhead. Finally, corner
C includes platforms with low overhead and many nodes, but with high finality. The
consensus mechanism of different platforms can, according to Zamfir, be described as
a specific point inside or on the edge of the triangle (Zamfir, 2017). However, it should
be noted that this model only describes the consensus aspect of a platform.

2.4 Rotating savings and credit association

This section describes the application developed for the study. Initially, an introduction
to rotating savings and credit associations (ROSCAs) as systems is presented, followed
by the pronouncement of its different design components. All information is intended
to facilitate the development described in chapter 5, and to allow for later assessment
and discussion.

2.4.1 Introduction to ROSCAs

ROSCAs are informal financial institutions for peer-to-peer saving and ledning, found
primarily in developing countries (J. Besley, Coate, & Loury, 1993). The motives
for ROSCA participation, described by Rangarirai Mbizi and Edson Gwangwava, are,
among others, the need to acquire consumer durables, insurance, and intrahousehold

16


conflict in resource allocation (Mbizi & Gwangwava, 2013). ROSCAs were histori-
cally formed with periodical contributions of grain of different sorts. Today, however,
ROSCAs generally use money as the subject to be transferred between its members
(Kabuya, 2015).

There are different ways to implement a ROSCA, but the basic idea can be described by
a general example (Ambec & Treich, 2007). Interested parties come together as mem-
bers of a group. This group holds regular meetings where every member contributes
to a common pot. At the end of a meeting, the common pot is given to one member
of the group. This member is then excluded from receiving the pot at future meet-
ings, but continues to contribute to the pot. When every member has been assigned the
pot once, a cycle is finished and the ROSCA either continues for another cycle or is
disbanded.

2.4.2 Rotation

The rotation of a ROSCA refers to the way in which the participants receive the pot.
For the system to be fair to its participants, the pot rotates between the members so
that every member has received the pot once every cycle. It is possible to create asso-
ciations without the rotation component where some participants obtain the pot every
time while others solely fund the pot. This type of association is no longer a ROSCA
but instead called an accumulating savings and credit associations, ASCA.

There are two distinct types of rotation implementations called random and bidding
(Kedir, 2015). A random ROSCA selects the order in which the members receive the
pot, at random. The member receiving the pot is still excluded from getting the pot at
future meetings, and thus only get the pot once every cycle. The difference for a bidding
ROSCA is that the members competitively bid for the pot at every meeting. The pot is
allocated to the highest bidder, which then is excluded from future biddings.

There are different ways to implement the bidding procedure. One possible bidding
technique, and the one used for this study, is the Vickrey auction. This is a type of
sealed-bid auction where participants submit bids without knowing the bid made by
other bidders. The highest bidder wins the auction but only pays the second highest
price. Note that the highest bidder in this auction is the one who can spare the biggest
amount of money. This could be implemented in a ROSCA by simply having the auc-
tion winner get the pot for the second highest price every meeting, and be dispossessed
of the right to place future bids. This procedure thus obtain a rotation for the receiver
of the pot.

2.4.3 Transactions of value

Transactions of value need to be handled within the association, and more specifically
between the members and the current receiver of the pot. This could be implemented
in a few different ways, the simplest being to physically exchange money during an

17


actual meeting. However, more modern ways of handling ROSCA transactions are
either by digital direct payments, or by using a digital common pot or fund possessed
by a member or a third party.

For certain implementations of the rotation, a common pot or fund is vital. This is
the case when implementing a rotation component as a Vickrey auction. As a conse-
quence of this, there needs to be a possessor of the pot or fund and thus be trusted by
all members of the association. This gives motive for implementing the ROSCA as
a distributed and decentralized application, given that the pot could be distributively
possessed.

2.4.4 Joining the circle

In order for a ROSCA to be established and operate it needs to have onboard mem-
bers. Member groups of traditional ROSCA implementations often include friends and
family. As these groups have a natural connection, they obtain the vital trust within the
association. However, as one major benefit of ROSCAs is the distribution of risk within
the group, it could be argued that ROSCAs with member diversity is to prefer.

One way to establish trust within a group is to write a common contract. Blockchain
platforms enable writing contracts online and keeping them decentralized. This can
theoretically allow members to be anonymous and yet participate in the association.
Furthermore, trust can be increased by specifying acceptance requirements for the
ROSCA participation.

2.4.5 Penalty

Another important aspect of a ROSCA is how to handle unwanted behavior among
members of the association. One example of such behavior is not paying the contribu-
tion to the common pot. The association needs to decide on appropriate penalties for
such event, giving participants incentive to act honestly. This aspect of a ROSCA ends
up outside the scope of this study. It is although necessary to mention the penalty as a
component in order to communicate an thorough design.

18


Chapter 3

Method

This chapter describes different aspects of the method used for this study. The first
section specifies the research design and aims to facilitate understanding and analysis of
the method used to obtain the results presented in chapters 4 and 5. This is followed by
a declaration of the limitations connected to the research design. Finally, an evaluation
of the method is provided.

3.1 Research design

The study aimed to obtain a gradually improving platform comparison framework,
based on different kinds of empirical data. Data was gathered by going through tech-
nical documentation on platforms, and by documenting the development process of a
ROSCA application. The framework for platform comparison was continuously up-
dated and revised. This was, however, all following the first challenge, to, through a
literature study, understand and describe blockchain technology, despite the conceptual
confusion discussed in the introduction.

3.1.1 Initial literature review

The study was initialized with a literature review on blockchain technology. By con-
sulting an expert in the area, the authors’ of this study were recommended the study
literature ”Bitcoin and Cryptocurrency Technologies” by Arvind Narayanan, Joseph
Bonneau, Edward Felten, Andrew Miller and Steven Goldfeder. This literature was
published by Princeton university press in 2016 and provides the reader with an expla-
nation on how the well known Bitcoin network is implemented, along with its under-
lying blockchain technology. Topics covered are the ones presented in the background
chapter.

Other sources has continuously been added to supplement the understanding of the
various fields included in blockchain technology. This information has come from
a variety of places, ranging from twitter posts from leading developers on a specific
blockchain platform to scientific articles found by Google scholar and Chalmers Uni-
versity library database. Specific search words included ”proof-of-work”, ”off-chain
transactions”, or ”distributed ledger technology”. It was however found that scien-
tific articles describing blockchain technology on a generally applicable level was
scarce.

19


Reading the abstract of an article was usually sufficient to assess its relevance and
weather to save it for the study or not. Additional sources found through different
Google searches could include newspaper articles and blog posts. To ensure the quality
of the blog posts, the focus was on posts written by people with a high reputation in the
blockchain community. Examples could be developers working for organizations such
as Ethereum. When using documents from web pages we downloaded the information
to assert that the information would be recoverable in the case that the web pages
changes or goes down. Finally, during the course of this study we have also used
unpublished information from ongoing current research provided by an expert on the
area working for RISE - Research Institute of Sweden.

A principle that has permeated the writing process for this report is an avoidance of
giving assertive definitions of confusing concepts. For such concepts and terms, the
definition presented is the one used in this report, and not necessarily the one that is
considered the correct definition by everyone.

3.1.2 Platform selection and examination

Three platforms were selected and examined. The selection was made by mapping
platforms to Zamfir’s triangle and selecting platforms near its different corners, to en-
sure a platform selection with as much variety as possible. Hyperledger Fabric, Neo,
and Ethereum were the three selected platforms.

The platform examination was conducted through reading technical documentation,
provided by the platforms’ original creators. The examination of Hyperledger Fab-
ric is based, unless otherwise stated, on the official documentation found on the Hy-
perledger web page (Hyperledger, 2018) (Hyperledger, 2019b). The examination of
Neo is based, unless otherwise stated, on the Neo organization’s technical documen-
tation (NEO Documentation, 2019). The examination of Ethereum is based, unless
otherwise stated, on the Ethereum whitepaper (Buterin, 2019) and yellowpaper (Wood,
2014).

The structure of the platforms’ description, found in Chapter 4, was set during the
initial literature review of blockchain technology and blockchain platforms. The struc-
ture details can be reviewed in Appendix A. The order of the information about the
platforms was coordinated based on the structure of the platforms’ documentation, and
with the intention to maximize readability. The structure can also be found in Appendix
A. Once examined and structured, information about the platforms was synthesized and
structured in a conforming way to enable a juxtaposition with each of them.

3.1.3 Development of ROSCA application

The synthesis of platform information, structured in different categories, were used
as a draft of a comparison framework, for mapping meaningful differences between
the examined platforms. The draft was first used to select one designated platform

20


to develop an application on. The choice fell on Ethereum, of reasons which will be
described in chapter 5. The development consisted of designing and implementing a
ROSCA. ROSCAs appeared among other alternatives during idea brain storming, and
was eventually picked primarily based on the reasonable scope of developing it and its
compatibility with being implemented on a blockchain.

At the beginning of the process, information needed to develop on the platform was
collected by using the documentation provided by platform creators and development
community. The reason for this was to put together a course of action related to con-
structing the application. After that, the development of the application could take
place, ending with a functioning ROSCA implemented and deployed on a blockchain
network. The development continued as long as the time limit allowed.

Each member involved in the development process continuously documented their
work in a diary. The diary contained information related to what had been done, which
obstacles were encountered, and how they were solved. At the end of the development
process, the diaries of each participant were analyzed. The aim was both to distinguish
which properties were of most importance when developing the ROSCA. However, a
reflection of whether the properties are of importance for other applications as well was
also initialized.

3.1.4 Concluding establishment of the final framework

Ultimately, the framework was reconsidered through discussion with input consisting
of data, both from the external examination of the platforms and from the experience
of developing a ROSCA application on Ethereum. Firstly, all differences between
platforms, collected during the development process, were discussed and evaluated.
Secondly, certain differences were pointed out as more or less meaningful when de-
veloping a ROSCA application. Even if the development only was carried out on one
platform, hypothetical differences between platforms were discussed with the use of
the data gathered in the platform examinations.

3.2 Limitations

The duration of the study was no more than about four months, and consequently, only
three platforms were examined. Other platforms could have been studied to provide
more details for the comparison framework. Regarding the development, there are two
distinct limitations. The first is that the development of a ROSCA was only conducted
on one platform due to the time limits. The second is that the development only resulted
in a minimal viable product and thus only highlights situations and obstacles occurring
in the initial phases of development. With more time, the development would also
include testing the application live with real participants.

21


3.3 Method evaluation

This evaluation starts off with a critical review of the various sources used for data
gathering. As scientific literature on blockchain is scarce, a critical approach to sources
is crucial to ensure the quality of the study. Afterward, a discussion regarding the
platform selection is held, unearthing the implications of the specific choice. Lastly,
some concepts regarding the quality of the study are discussed.

3.3.1 Source evaluation

The concept of source evaluation that has been used during the study is called func-
tional source concept (Blomkvist & Hallin, 2015). The concept is best described
by the quote, “no source in itself is bad or worthless” (Blomkvist & Hallin, 2015).
This implies that it is more important how to use sources rather than what sources to
use. However, it is important to note that sources that are not academic have not gone
through the process of peer review. This needs to be taken into account when assessing
their credibility. Examples of such sources being used are articles from web pages,
blog posts, and the ongoing work of unpublished material provided by an expert in the
area.

Social media, blogs, and forums have increased in importance since information is
more and more available online (Shneiderman, 2016). It implies that academia no
longer is at the forefront of research in all areas. The consequence of this is that crowd-
sourcing is becoming an increasingly powerful way of conducting research. This be-
comes highly relevant for this study since blockchain has become closely associated
with decentralization through its peer-to-peer characteristic. Therefore, the importance
of combining applied and basic research have increased (Shneiderman, 2016). Ap-
plied research is characterized by a mission-driven and a solution driven approach, in
which the aim is to find practical guidelines. The ideal scientific approach is therefore
deselected in favor of a more realistic approach to finding the answers wanted. Ba-
sic research is more traditional, theory-driven, and uses classical scientific principles.
The combination of these two is what is recommended, and what this study builds
on.

3.3.2 Platform selection

The choice of platforms had to be carefully considered to ensure diversity among the
three platforms that were enough to provide a solid comparison framework for later
assessment. The three platforms were selected with the use of Zamfir’s triangle and
by using the fact that these were close to the triangle’s extremes. The extremes refer
to the corners A, B, and C in Figure 2.3. The reason for choosing platforms mapping
to the extremes in Zamfir’s triangle is that this was believed to be the most suited
way to select three platforms that potentially could generate the greatest variety for

22


discussing meaningful differences. The three platforms are not important themselves
but are chosen to represent a diversity to form a framework from.

3.3.3 Contribution of the development

The development was necessary as an input to the discussion about meaningful prop-
erties. However, the character of the development as a tool for research comes with
some limitations. Firstly, the method is subjective in the meaning that it is reliant on
the knowledge and efficiency of the developers. It is possible that another development
team would have encountered other obstacles while developing the same application.
Since only one specific application was implemented, on a particular platform, there
are limitations to the insights’ general applicability, which is further discussed in the
6.

3.3.4 Generalizability and usefulness

A qualitative research study could be evaluated by using a couple of quality criteria
(Flick, 2014). Those extra debatable in the context of this study will be discussed,
namely generalizability and usefulness. Generalizability can be described as the de-
gree to which the result of the study can be generalized outside the context of this
study. Usefulness measures whether the conclusions from this report can be used by
potential readers in their everyday lives (Flick, 2014). Generalizability and usefulness
are closely intertwined for this study. Even if the three platforms studied are three
of the most used among blockchain platforms, the conclusions are much more useful
if the resulting framework for comparison can be used when choosing between other
platforms too. The most persuasive argument for the generalizability of this study is
that the platforms were selected to be as different as possible according to Zamfir’s tri-
angle. The platform examination questions presented in Appendix A were used when
comparing the three platforms in this study. These questions were developed over time,
and new questions were added when new differences were identified. This structure of
questions could be generalized and used for other platforms too even if some tweaking
of it may be required. This means that the quality of the output from this study if this
proves to be true and in terms of generalizability and usefulness, is to be considered
strong

23


Chapter 4

Platforms

Three different blockchain platforms were chosen because of their difference accord-
ing to Zamfir’s triangle (Zamfir, 2017), illustrated in figure 4.1. The triangle symbols
a three-way tradeoff between latency, overhead cost and number of nodes. First, Hy-
perledger Fabric is a framework for designing networks with low latency finality, low
overhead and a few nodes. Second, Neo consists of an own network, also with low
latency finality, but with high overhead and many nodes. Third, Ethereum is a net-
work that has high latency, low overhead and many nodes. The platforms have been
examined and later evaluated for their suitability for developing the ROSCA system
described in section 2.4. In this section, platforms will first be described individually,
to afterwards be juxtaposed with each other in a synthesis table in section 4.4.

Figure 4.1: Zamfir’s triangle with Hyperledger Fabric, Neo and Ethereum (Interpreta-
tion of original figure from Vlad Zamfir’s twitter (Zamfir, 2017))

4.1 Hyperledger Fabric

Hyperledger Fabric is one of six open source blockchain solution frameworks made
available by Hyperledger, hosted by the Linux Foundation. Hyperledger provides both
blockchain frameworks and several tools for additional functions. The basic idea for
Hyperledger Fabric is allowing different companies and organizations, not necessarily

24


trusting each other, to share a global up-to-date state of data that are in all parties’
interest.

A possible alternative solution would have been for each company to supply their own
data storage. The problem would then be that only the company itself could change
the data. If the state of the data demands other companies’ and organizations’ input in
order to be consistent, this solution is not effective. To keep a consistency of data, a
third party, trusted by all involved parties, could keep the data and distribute it. This
requires a third party that everyone trusts and that can provide the demanded services.
Thus, this solution also establishes an undesirable, low fault tolerance.

The solution Hyperledger Fabric suggests is for the involved companies and organi-
zations to share a distributed ledger. The companies will each hold an access node
necessary in order to reach the information and modify the current state of the data.
The parties state a way in which the permitted distributed system should operate and
can thus all hold and manipulate the ledger while always being consistent with other
network participants.

The Hyperledger Fabric framework is modular and allows permitted users and creators
to modify the network configuration in order to make the network suit a specific pur-
pose. A network can consist of many channels, and each channel is associated with its
ledger. A channel is a group of organizations that share a distributed ledger, and thus
can share private information with each other.

4.1.1 System design

A Hyperledger Fabric network is built around one or many distributed ledgers. The
blockchains are permissioned which, in practice, means that only permitted organiza-
tions have access to the blockchain data. All network participants need to be connected
to an organization node in order to get access to the blockchain.

The configuration of a Hyperledger Fabric network is as already stated modular which
means different parts of it can be adjusted freely to suit the creator’s purposes. In the
network configuration, it is stated which organizations have access to what parts of the
network. The network configuration is established by the initial network creator which
could be either an organization within the network or a third party.

Data structures

As illustrated in figure 4.2, the ledger of Hyperledger Fabric is comprised of two data
structures. One is representing the ledger state, and one is constituting the blockchain.
The ledger state is implemented using a database, holding a cache of the current ledger
state. The blockchain does not store the data itself, but rather the history of transactions
leading up to the current state.

The database keeping the ledger state is exchangeable. The state database could be
a graph store, a relational database, or a temporal database. Thus, the structure of

25


Figure 4.2: Modelling of Hyperledger Fabric’s ledger (Interpretation of figure from
Hyperledger Fabric documentation (Hyperledger, 2019a))

the data may vary between networks. Regardless of the implementation, the database
is updated for every new block of transactions appended to the ledger, ensuring the
database contains the current ledger state. LevelDB is the default implementation of
the database which uses a key-value structure to store its data. For ledgers that are
structured as JSON documents, CouchDB is described as the preferred database to use.
It structures its data as JSON objects, which enable nesting of data points into objects
and arrays.

The blockchain is structured as sequentially linked files, illustrated in figure 4.3. Each
file is referred to as a block and contains three sections. The block header contains the
block number, the hash of the previous block, and the current block hash. A list of
transactions is gathered as the block data. Finally, the block also contains block meta-
data containing information about certificates, the time when the block was created,
and the signature of the block writer.

Figure 4.3: Model of Hyperledger Fabric’s blockchain (Interpretation of figure from
Hyperledger Fabric documentation (Hyperledger, 2019a))

26


Participants

There are different actors with different roles and capabilities within the Hyperledger
Fabric network. Two different network participants play a vital part in the flow of the
network.

The first of the two is a peer node. To access a ledger, an organization need to run a peer
node. A peer node is a container in which the owner organization’s different channel
ledgers are situated. The container also stores and executes the channel chaincode,
which is Hyperledger’s counterpart of a smart contract. The node is unique to every
network organization. If an organization require lots of interactions with the network,
it is possible to possess many peer nodes connected to the same channel.

The other participant is the ordering node. The best way to describe an ordering node
is as the administrative point of the network. The ordering node is provided by an orga-
nization and initiates the network configuration and thus the channels. A network can
contain many ordering nodes from different organizations. In that case, the ordering
nodes together shape the administrative service for the network.

Consensus mechanism

As described in 2.1.4, the consensus mechanism can be divided into two parts: a con-
sensus model, and a consensus algorithm. The consensus model defines the network
of participants engaging in the consensus process as well as important properties and
rules. The ordering nodes, as the administrative service of the network, are defined in
the network configuration. This configuration also defines the endorsement policy of
the network.

The consensus algorithm is a three-step process. The easiest way to illustrate this pro-
cess is to describe the way in which a new transaction is added to the ledger. The initial
step is called endorsing. In this phase, the peers required for the specific transaction are
required to digitally sign the transaction in order to agree that it should be processed.
The number of endorsements as are necessary for the transaction, as well as what peers
are required to endorse is defined in the consensus model. The transaction is then sent
to the ordering nodes of the network which run a pBFT algorithm to find consensus
on the order of the new incoming transactions. As the third step, when the ordering
nodes reach consensus, the transaction is broadcast on the channel, where peers run a
validation on the transactions to verify that the ordered transactions are correct, before
appending them to their ledger.

Value on the system

There are no inherent cryptocurrencies in the design of the Hyperledger Fabric frame-
work. It is possible to create cryptocurrencies and token applications on the platform
through the use of chaincode.

27


Interacting with the system

Each shared ledger in a channel has a chaincode defining the operations available to
modify the state of the ledger. Modifying the state creates a transaction which will
pass through the consensus algorithm for the transaction to be endorsed, ordered and
validated by peers in the channel.

A new transaction, intended to update the ledger state, is constructed in a specific way.
The transaction contains a header with data about the chaincode and the chaincode
version, a signature of the client application, the proposal as the input parameters to
the chaincode creating the proposed ledger update, the response as the before and after
the value of the proposal, and lastly endorsements of the transaction.

A query for information about the current state of the ledger can be sent to the peer node
which holds the database with the current state. This is considered a read-only transac-
tion and is therefore not required to broadcast as a data transaction of the ledger.

Access and privacy

In order to ensure that a blockchain network is permissioned, there need to be com-
ponents to manage network identities for the network’s organizations. A membership
service provider (MSP) is the component handling this in Hyperledger Fabric. A MSP
is an abstraction of a variety of access protocols and is installed to each node in the
network. It can then operate as a validator for incoming transactions to the node. By
the use of different cryptographic protocols, an identity can be connected to an organi-
zation and thus be granted access to the node.

4.1.2 System performance

Hyperledger Fabric is a modular blockchain framework and has not, according to IBM,
yet been performance-tuned and optimized (Androulaki et al., 2018). Due to the mod-
ularity of the framework, the system performance depends on a number of parameters.
These parameters include the choice of application, transaction size, the ordering ser-
vice, the consensus implementation, the number of ordering nodes in the network, the
hardware on which the nodes run, and further configuration parameters.

Computing performance

IBM has studied the performance of the Hyperledger Fabric framework by evaluat-
ing it with respect to the number of transactions that can be performed per second
(Androulaki et al., 2018). However, the performance is affected by several factors, and
due to the modularity of the framework, separate networks can be designed and opti-
mized for different purposes. Therefore, different Hyperledger frameworks can have
varying performance seen to transaction throughput etc.

28


The application created to study the performance was designed as a UTXO cryptocur-
rency using a key-value database. Nodes were running on the Hyperledger Fabric
version 1.1 instrumented for performance evaluation, hosted in IBM Cloud virtual ma-
chines interconnected with 1 Gbps networking. The nodes were 2.0 GHz 16-vCPU
with 8 GB RAM and SSDs as local disks. The network had three ordering nodes,
and five peer nodes, all being endorsing peers. Separate virtual machines ran all
nodes.

The factors that shifted were the block size and the number of CPU for each peer.
Block size of between 0.5 MB, and 4 MB was considered, and the result showed that
the network managed over 3000 transactions per second for block sizes over 2 MB.
Smaller blocks had a lower throughput and bigger blocks slightly higher. The end-to-
end latency was continuously increasing with greater size of the blocks.

The block size was set to 2 MB when testing the effect of the number of CPUs for each
node. The result showed that increasing the number of CPUs affected the transaction
speed positively. The transaction speed was just over 1000 transactions per second
when running the nodes on 4 CPUs. The corresponding number for 32 CPUs was
slightly below 3500 transactions per second.

System stability

The stability of the developed network is directly connected to the stability of the partic-
ipating peer nodes and ordering nodes. Increasing the number of nodes would increase
the fault tolerance and thus the system stability. The stability of the system can vary
between different networks due to the networks’ different setups. The fact that the net-
work is permissioned gives the creators increased influence over the system stability.
However, the default consensus algorithm, pBFT, entails a fault tolerance of 1

3 (Bach
et al., 2018).

4.1.3 Platform ecosystem

Hyperledger Fabric is part of the Hyperledger greenhouse. The greenhouse is a col-
lection of frameworks and tools to let blockchain technologies and ideas co-evolve and
emerge. While there is a focus on solving problems with enterprise implementations,
the code is open source and available to anyone for usage and contribution.

Programming possibilities

Hyperledger is, as previously stated, a framework and serves only as a foundation for
developers to create their blockchain solutions. Consequently, the framework gives
the developers full control of how the system is implemented and how it will oper-
ate.

29


Chaincode is written in one of three general-purpose programming languages: Go,
node.js, or Java, and runs in a docker container in order to separate it from the peer it is
executed on. The state created by the chaincode can only be accessed by that contract.
Contracts can, however, be given access to other contracts which means they can access
their state through the given transactions.

Developer community

Hyperledger provides not only the possibility for developers to contribute to the open
source code, but also a vast guide about how to both understand the key concepts of
Hyperledger Fabric, but also about how to create applications. Hyperledger encourages
users to help develop the training material, spread the word about Hyperledger, and to
engage in meetups on different locations and times. The organization refers to their
code of conduct describing accepted and acceptable behaviors to promote high stan-
dards of professional practice. The official GitHub repository of Hyperledger Fabric
consists of 9090 commits from 168 contributors (Hyperledger, 2019).

User access

Data and information from the ledger can be accessed from outside of the network by
a client application. The client application is connected to an organization and can
connect to one of the organization’s peer nodes which will provide ledger access and
information through the chaincode transactions.

Hosting costs

The Hyperledger Fabric framework does not specify any fees for computation through
deploying, ordering or validating chaincode.The endorsing nodes and ordering nodes
participating in the consensus mechanism are not incentivized by on-chain tokens or
cryptocurrencies, but rather to avoid off-chain costs connected to malicious behavior.
Because of this, transaction and execution do not have to exist if not desired. Instead,
the costs for an application being developed is consisting of both the writing of the
chaincode and the configuration of the system itself. When developed, the creators also
need to provide their infrastructure for running the system. Every participating node
needs to set up their peer node, and endorsers and orderers need to be compensated
outside the system.

Areas of usage

The solution of Hyperledger Fabric is mainly intended for business-to-business in-
teractions. Use cases, according to IBM, include areas such as trade logistics, dis-
pute resolution, foreign exchange netting, contract management, food safety, diamond

30


provenance, rewards point management, identity management, low liquidity securi-
ties trading and settlement, and settlement through digital currency (Androulaki et al.,
2018).

4.2 Neo

Neo is an open source blockchain project with the purpose to establish a platform for
managing all types of assets, through the use of digital assets, digital identity and smart
contracts. The digital assets represented in the system are of two types. Global assets
are exchangeable on the entire platform, whereas contract assets require access to the
contract the asset is issued on. On Neo, anyone can issue both global and contract
assets.

4.2.1 System design

Neo’s blockchain structure is consisting of a hash linked list of transaction blocks as
described in 2.1.1. The system does use a transaction model with account balance
redundancy to model the state. The consensus mechanism, dBFT, is based on the
election of validator nodes.

Data structures

Neo relies on a blockchain architecture that is in many ways similar to other known
blockchains. Neo does, in addition to the UTXO model, use account states to model
the state. The UTXO model is used for global assets, whereas the account model is
primarily used for contract assets. Note that there are no additional data structures con-
nected to the block used to record account states. Thus, no mapping between accounts
and their balances are recorded systematically in the blockchain. Instead, validator
nodes need to maintain data sets with states and contracts separately.

Participants

There are two types of nodes defined in the protocol. Peer nodes, that can broadcast,
receive and transfer transactions or blocks, and validator nodes that can create new
blocks. Peer nodes accept the state of the ledger produced by valid transactions signed
by validator nodes. These bookkeep transactions in order to maintain the ledger.

Consensus mechanism

Neo uses a consensus mechanism called dBFT, as described in the background chap-
ter. As other consensus mechanisms, it can be divided into a consensus model and a

31


Figure 4.4: Modelling of Neo’s blockchain implementation (Interpretation of figure
from Neo Organization (NEO Documentation, 2019))

consensus algorithm respectively.

The decision model consists of an election of validating nodes. NEO holders that have a
stake in the network decide upon several validator nodes, and a specific list of validator
nodes, i.e., nodes that gets the privilege of producing and validating new blocks. This
voting is connected to holders public addresses and recorded in every block.

In Neo’s consensus algorithm, the elected validator nodes take turns to produce the next
block. Sequentially, the other validator nodes make a majority decision on whether to
accept the block or not.

Value on the system

The economic structure on the network is based upon the two global assets NEO and
GAS. NEO can be seen as stakes in the platform, which gives its holders mandate to
manage the network and for example vote for validator nodes. NEO holders get shares
of the other global asset, GAS, as it is continuously issued, and also gets paid in GAS
when assets are registered on the network. The smallest amount of NEO existing is 1
NEO, and it cannot be further divided. GAS is used to pay for system operations, i.e.,
compensating validating nodes for their validating. This whole structure, in theory,
works to hold down transaction costs. If higher transaction costs are induced, fewer
actors will register assets on the platform. Hence, NEO holders will get less compen-
sation for assets registered. This gives NEO holders the incentive to vote for low-cost
validators, who will yield them more value.

32


Interacting with the system

In Neo, transactions are the way for individuals and smart contracts to operate with
the system. To be executed, a transaction needs inputs and outputs, to signal which
UTXOs that are going to be used and produced respectively. There are nine transactions
defined, according to Table 4.1.

Transactions in the Neo Protocol
Transaction System Fee Description
MinerTransaction 0 GAS Assign byte fees
IssueTransaction 0-500 GAS Inssuance of asset
ClaimTransaction 0 GAS Assign GAS
EnrollmentTransaction * 1000 GAS Enrollment for validator
RegisterTransaction * 10000 GAS Assets register
ContractTransaction 0 GAS Contract transaction
PublishTransaction * 500 GAS Special Transactions
InvocationTransaction 0 GAS Special transactions

Table 4.1: Transactions and fees in NEO, interpreted from (NEO Documentation,
2019). Transactions marked with (*) are deprecated and replaced with system opera-
tions. Fees are still the same for corresponding operations.

Access and privacy

The Neo network is accessible for use by anyone that wants to participate. To take
part, only creating an account represented by a public key is needed. Neo’s intention
is to let participants get transactions prioritized through use of public identity, and if
there is a wish to be anonymous, one can pay transaction fees to be prioritized instead.
However, to be part of the validation process, nodes need to be elected by NEO holders.
For individuals, this process is similar to a political election, since candidates need to
identify themselves and argue why they should be elected.

4.2.2 System performance

This section intends to give insight to the system performance of the Neo platform
by analyzing several different component. All things considered, Neo’s consensus
mechanism makes the system efficient in terms of transaction processing. However,
a high degree of centralization makes the network reliant on a few numbers of valida-
tor nodes.

33


Computing performance

The design parameters of its consensus mechanism makes Neo’s validation process
very effective seen to transaction processing time, and at the same time more efficient
in terms of energy consumption than a proof of work algorithm. The Neo network
today is taking 15 to 20 seconds to generate a new block. It can process around 1,000
transactions per seconds, and 10,000 transactions per second might be achievable with
proper optimization.

System stability

The consensus algorithm entails that the fault tolerance f of the network is

f = b(n−1)/3c

where n is the total number of validator nodes, since the validating nodes always choose
one single valid block to continue building on. The Neo blockchain is also character-
ized by an attribute called immediate finality. As long as the fault tolerance is not
exceeded there is consensus on exactly how the entire blockchain looks.

Currently, there are only seven validating nodes. Out of these, only one is controlled
by an actor not directly related to the Neo organization. The reliability of Neo is highly
connected to the validating nodes and these therefore have a public identity. This is to
facilitate legal measures if some of the nodes would act maliciously.

4.2.3 Platform ecosystem

To make Neo accessible for developers, it has been made compatible with several main-
stream programming languages. The organization behind the platform strives to estab-
lish a strong community around it, which however is still in its early stages.

Programming possibilities

The Neo network enables developers to code in their own preferred languages. Lan-
guages such as C#, Java and Python can all be used for coding smart contracts, which is
intended by the original creators to be accelerating for the network since programmers
do not need to learn a new language.

Developer community

Neo is an open source development project, and the organization expresses a vision of
building a strong development community. The community provides several tools and
softwares, such as development kits and smart contract compilers, planned on being
supportive for developers to maximize the potential of the development ecosystem. As

34


of May 4th, 2019, the official GitHub repository of Neo has 32 contributors of which
the founder, Erik Zhang, is the biggest seen to lines of code (Project, 2019).

User access

The Neo organization supports different types of node programs, where participants
can either be full nodes or light nodes. There are both desktop, and mobile clients
available for download, which do not need to store the entire blockchain to function.
Hence, the only thing needed of users is to create an account on the platform. With
access to the contract address they are ready to interact with the application.

Hosting costs

The Neo network is an already established network, meaning a developer of an ap-
plication can deploy contracts without needing to set up an entire infrastructure. De-
velopment costs are therefore solely consisting of the costs for developing the smart
contract.

Validating nodes do get compensated with transaction costs. However, their public
identity also incentivizes them to behave honestly since legal measures can cost them
outside the network, and their reputation can be damaged. Transaction costs are zero as
default, and every block contains a maximum of 21 free transactions. Users are though
recommended to pay transaction fees to be prioritized by validators.

Deploying a contract on Neo comes with a fixed cost and is the most expensive cost
when launching contracts on the platform. One single contract deployment implies a
cost of 500 GAS. Operation costs, however, are cheaper. The fee for writing to the
account specific, persistent storage is set to 1 GAS per KB, and a get-operation costs
0.1 GAS. Since the initial 10 GAS of every smart contract execution is free, a lot of
transactions can be done for free on the network.

Areas of usage

The Neo network has as already mentioned an outspoken focus on digitizing assets.
Its compatibility with PKI (Public Key Infrastructure) X.509 standard lets users and
asset issuers provide their identity if necessary, enabling registration of both digital
and physical assets.

Of the applications existing today, most are focused on B2C solutions. Examples are
a music trading platform, a peer-to-peer shipment solution, and various saving and
general purpose trading platforms.

35


4.3 Ethereum

Ethereum is, as stated by the Ethereum foundation, ”a decentralized platform that runs
smart contracts”. It is designed to facilitate the development of decentralized applica-
tions, in