See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/325430598

Towards Blockchain-enabled Wireless Mesh Networks

Conference Paper · June 2018

DOI: 10.1145/3211933.3211936

CITATIONS READS
12 68

5 authors, including:

Aniruddh Rao Anwaar Ali

Samsung University of Cambridge
12 PUBLICATIONS   40 CITATIONS    15 PUBLICATIONS   283 CITATIONS   

SEE PROFILE SEE PROFILE

Leandro Navarro
Universitat Politècnica de Catalunya
246 PUBLICATIONS   1,335 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Healthcare informatics View project

Blockchain-enabled Wireless Mesh Networks View project

All content following this page was uploaded by Aniruddh Rao on 24 June 2018.

The user has requested enhancement of the downloaded file.

 Towards Blockchain-enabled Wireless Mesh Networks
Mennan Selimi Aniruddh Rao Kabbinale
University of Cambridge and University of Cambridge
Ammbr Research Labs Cambridge, UK
Cambridge, UK

Anwaar Ali Leandro Navarro Arjuna Sathiaseelan

University of Cambridge UPC BarcelonaTech and Ammbr Research Labs
Cambridge, UK Ammbr Research Labs Cambridge, UK
Barcelona, Spain
1
ABSTRACT the Internet access [9]. Guifi.net is an example of such a com-
Recently, mesh networking and blockchain are two of the munity effort which is one of the biggest community networks
hottest technologies in the telecommunications industry. in the world, with more than 34,000 participating routers.
Combining both can reformulate Internet access. While The idea of CMNs, nobel as it seems, does not come with
mesh networking makes connecting to the Internet easy out its fair caveats. Since the nature of CMNs is peer-to-peer
and affordable, blockchain on top of mesh networks makes there are concerns related to trust among various participating
Internet access profitable by enabling bandwidth-sharing peers and how to make this volunteer effort economically
for crypto-tokens. Hyperledger Fabric (HLF) is a blockchain viable and sustainable as well [3].
framework implementation and one of the Hyperledger As an example scenario we consider the economic compen-
projects hosted by The Linux Foundation. We evaluate HLF sation system in Guifi.net [3]. The idea of the compensation
in a real production mesh network and in the laboratory. We system is to create a balance between total resource con-
quantify the performance, bottlenecks and limitations of the tribution and its consumption. The economic value of the
current implementation v1.0. We identify the opportunities contribution and consumption of network resources for each
for improvement to serve the needs of wireless mesh access participant in a given locality are recorded. The overall
networks. To the best of our knowledge, this is the first HLF result is a zero-sum budget where the participants with
deployment made in a production wireless mesh network. over-consumption or negative balances, have to compensate
those with over-contribution or positive balances.
1 INTRODUCTION Currently the above described economic compensation
system is managed manually. What this means is that a
Network infrastructure is critical to provide local and global
participant puts forward claim of its consumption and
connectivity that enables access to information, social 2
then the Guifi.net foundation validates this claim by cross
inclusion and participation for everyone. Local connectivity
checking it with their own network traffic measurement data
largerly relies on access networks. Wireless mesh networks
and network inventory. Any disparities between these two
(WMNs) are a kind of access networks comprising of wireless
records are flagged. There is, however, room for errors or
nodes namely wireless mesh routers and wireless mesh clients.
even malicious activities such as false claims put forward
A client (irrespective of whether it is a mesh or a generic
by a participant, the recorded data being tampered with,
client) can access the Internet through a WMN [1].
or simply mistrust among the parties. There is a need for a
Community networks are network infrastructure commons,
system where participants can trust that the consumption of
built by citizens and organizations which pool their resources
resources is being accounted in a fair manner, and that these
and coordinate their efforts, characterized by being open, free
calculations and money transfers are done automatically to
and neutral [5].
avoid the cost, delays, errors and potential mistrust from
Community Mesh Networks (CMNs) are a special case of
manual accounting and external payments.
WMNs which are usually setup as a community network. The
Blockchain is one of the solutions that seems quite apt
CMNs have been identified as one of the models contributing
to make the peer-to-peer nature of CMNs trusted and
to connecting the next billion people that are still without
economically sustainable. Blockchain (more details in Section
Permission to make digital or hard copies of all or part of this work for 2) is an immutable and distributed data storage without the
personal or classroom use is granted without fee provided that copies provision of retrospective mutation in data records. However,
are not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights
most blockchain networks are open and permissionless that
for components of this work owned by others than ACM must be honored. encourage the users to be anonymous [10]. This implies that
Abstracting with credit is permitted. To copy otherwise, or republish, anyone, without revealing their true identity, can be part of
to post on servers or to redistribute to lists, requires prior specific per-
mission and/or a fee. Request permissions from [email protected].
CryBlock’18, June 15, 2018, Munich, Germany
© 2018 Association for Computing Machinery. 1
ACM ISBN 978-1-4503-5838-5/18/06. . . $15.00 https://guifi.net/
2
https://doi.org/10.1145/3211933.3211936 https://fundacio.guifi.net/Foundation
1

13
CryBlock’18, June 15, 2018, Munich, Germany Selimi.et al.

such a network and make transactions with another similarly 2.0.1 Open and public blockchains. Blockchain of Bitcoin
4
anonymous peer of the network. [10], Ethereum [15], and in general of various other cyp-
In the perspective of CMNs, however, such as in Guifi.net tocurrencies are mostly open and public. This means that
every participant who joins the network to contribute to the anyone can be a part of the blockchain’s network and make
infrastructure must first register its identity and the identity transactions with other parties. Some degree of anonymity
of the resources that it contributes to the wider pool. This is is also at the heart of such platforms. A user (or in general an
particularly needed so that a malicious entity, such as hidden entity) usually uses the hash of its public key as its identifier
nodes in Guifi.net used by other ISPs to provide services to as opposed to using its real-world credentials. In the aspect of
their users, can be filtered out [11]. Because of such registration openness the permissioned blockchains are in sharp contrast
process one also needs an efficient identity mechanism on with public blockchains which we discuss next.
top of blockchain’s immutable record keeping. Permissioned
blockhains are part of such solutions. These blockchain 2.0.2 Permissioned blockchains. Permissioned blockchains,
solutions are mostly envisioned for business networks where a concept particularly popularized by the Linux Foundation’s
there is often a stringent requirement of know your customer in Hyperledger, are usually considered for business applications.
addition to keeping the intra- and inter-business transactions In such applications the identity of users, in addition to
3 trusted and immutable data storage, is also important such
confidential. Hyperledger (see Section 2.1 for details) is
one such solution that realises the concept of permissioned as the stringent requirement of know your customers for
blockchains and one which we also use in our current study. many businesses. Hyperledger tries to leverage the best of
In this study we explore combining CMNs with a permis- both worlds by implementing a cryptographic membership
sioned blockchain that can result in decentralized mesh access service on top of blockchain’s trusted, immutable, and
networks that make connecting to the Internet not only easy distributed record keeping. In our study the requirement
and widespread, but trustful and more economical as well. of both users’ identity and trusted record keeping is of
Our key contributions are summarized as follows: paramount importance and that is why we decided to conduct
our study using Hyperledger Fabric, which we discuss next.
∙ First, we deploy the HLF platform in a production wire-
less mesh network that is part of Guifi.net. We quantify 2.1 Hyperledger Fabric (HLF)
the performance of the platform in terms of different
metrics such as transaction confirmation/completion Hyperledger Fabric (HLF) is an open source implementation
latency, CPU utilization and memory utilization of of a permissioned blockchain network that executes dis-
HLF components. To the best of our knowledge, this is tributed applications written in general-purpose programming
the first HLF deployment made in a production wireless languages (e.g., Go, Java etc) [2]. HLF’s approach is modular,
mesh network. which implies that the platform is capable of supporting
∙ Second, driven by the findings in a mesh network, we different implementations of its different components (such
propose a placement scheme for HLF components that as different consensus protocols) in a plug-and-play fashion.
optimizes the performance of the blockchain protocol. The HLF architecture comprises of the following compo-
nents:
2 BLOCKCHAIN: Peers: Peers can further be of two types namely endorsers
THE UNDERPINNING TECHNOLOGY and committers. A peer is called a committer when
it maintains a local copy of the ledger by committing
Blockchain is an append-only immutable data structure. Its transactions into its blocks. A peer assumes the role
first incarnation was in the Bitcoin cryptocurrency network of an endorser when it is also responsible for simulating
[10]. Blockchain was used to enable trust in financial trans- the transactions by executing specific chaincodes and
actions among different non-trusting parties in a pure peer- endorsing the result (see the next subsection 2.2). A
to-peer fashion without the need for going through a third peer can be an endorser for certain types of transactions
financial party like e.g., a bank. Such trust is provided in terms and just a committer for others.
of immutability of blockchain’s data structure. Each block in Ordering service: The role of this component is to order the
blockchain contains information that is immutable. The im- transactions chronologically by time stamping them
mutability aspect is rendered true by including the hash of all to avoid the double spend problem [10]. The ordering
the contents of a block into the next block which also chains the service creates new blocks of transactions and broadcast
blocks together. Tampering with one block disturbs the con- them to the peers which then append these blocks
tents of all the following blocks in the chain. Each block in the to their local copy of the blockchain (or ledger). The
chain is appended after a consensus is reached among all the ordering service can be implemented as a centralized
peers of the network. The same version of a blockchain is stored or decentralized service [14]. It is at the ordering service
in a distributed manner at all the peers of the network. That level where the consensus (like proof-of-work in Bitcoin
is why it is sometimes referred to as distributed ledger as well. [10]) related to the state of a blockchain takes place.

3 4
https://www.hyperledger.org/ https://ethereum.org/
2

14
Towards Blockchain-enabled Wireless Mesh Networks CryBlock’18, June 15, 2018, Munich, Germany

Order Tx & create a block. Send

5
Chaincode: A chaincode or a smart contract is a program code block to all peers in the channel

Ordering
Ordering

nodes
that implements the application logic. It is run in a
Service
distributed manner by the peers. It is installed and in-
stantiated on the network of HLF peer nodes, enabling in-
Simulate/Execute Tx,
2
teraction with the networks shared ledger (i.e., the state Peer 3
endorse YES/NO

Endorsing Peers
of a database modeled as a versioned key/value store).
Peer 2
Channel: A channel provides a higher layer of confidentiality
abstraction. A channel can be considered as a subnet Peer 1
Verify endorsement
6
on top of a larger blockchain network. Each channel and readset

has its own set of chaincodes, member entities (peers Client

Client generates a Assemble endorsement into Notify client whether Tx
and orderers), and a distinct version of a distributed Tx proposal
Collect endorsement
a Tx. Send Tx to Ordering Service was valid or invalid

ledger. This should not be confused with a similar term, 1 3 4 7

payment channels, used to make multiple off-chain

micro-payments, multiple transactions, without Figure 1: Hyperledger Fabric Protocol
committing all to a blockchain.

2.2 HLF Protocol step) that will in turn ultimately update the ledger’s
Figure 1 depicts the sequence of transaction execution steps state as per the Tx simulation outcome in the last step.
in HLF’s environment. The description of these execution It can also happen that in the Tx proposal, made in
steps are as follows: the last step, only the current state of the ledger was
queried. In this case there will be no need to update a
1. Transaction (Tx) proposal: In this step clients access the ledger’s state and hence there is no submission to the
HLF blockchain to submit a proposal for a Tx to be Ordering Service by the client. In Figure 1 this is shown
included in one of the blocks of the HLF blockchain. by step three.
Clients propose a transaction through an application 4. Tx submission to the Ordering Service: The Ordering
that uses an SDK’s (Java, Python etc) API. This is Service collects various Txs after the last step via
shown as the first step in Figure 1. various channels. This is step four in Figure 1.
2. Endorsement and Tx simulation: The transaction proposal 5. Tx ordering: Ordering Service orders various Txs according
from the above step is then broadcasted to the to their receiving times. This ordered set of Txs is
endorsing peer nodes in the HLF blockchain network. then included in a block, specific to a channel, which
Each endorsing peer verifies the Tx proposal in terms will later be appended in the channel’s ledger. This is
of its correctness (i.e., its structure, the signatures that covered by step five in Figure 1.
it contains, and the membership and permission status 6. Tx validation and committing: In this stage all the peers
of the client that submits the transaction) uniqueness belonging to a particular channel receive a block
(i.e., this proposal has not be submitted in the past). containing Txs specific to this channel. Each peer then
After the above checks comes the transaction simulation checks all the Txs in terms of their validity. Valid Txs
step. Endorsing peers invoke a relevant chaincode (as are those that satisfy an endorsement policy. If the
specified in the Tx proposal by the submitting client). Txs pass the validity test then they are tagged as valid
The execution (as per specific arguments specified in otherwise invalid in a block and then this block is finally
Tx proposal) of this chaincode produces an output appended to the ledger maintained by the peers of this
against the current state of the database (ledger). channel. This is covered by step six in Figure 1.
Without updating the ledger’s state, the output of 7. Ledger update notification: Finally, after the ledger update
the Tx simulation is sent back in the form of proposal in the last step the client of the submitting Tx is notified
response back to the client through the SDK. In Figure about the validity or invalidity of the Tx that was
1 this is shown by the second step. included in the latest block of the channel’s distributed
3. Inspection of proposal response: After the above step the ledger. This is step seven in Figure 1.
client-side application collects the responses from the
endorsement step. Afterwards all the responses are cross 3 CASE STUDY: QMPSU MESH
checked (in terms of the signatures of the endorsing 5
peers and the content of the responses) to determine The Quick Mesh Project (qMp) develops a firmware based
if there are any disparities among the content of the on OpenWrt Linux with the aim to ease the deployment of
responses. If the content of all the responses are the same mesh networks by the users who are willing to interconnect in
and according to the pre-defined endorsement policy an area, and pool their Internet uplinks [6]. qMp was initiated
(i.e., number of peers whose endorsements—in terms of in 2011 by a few Guifi.net activists.
their signatures—are necessary) then the client submits
this Tx to the Ordering Service (more on it in the next 5
http://qmp.cat/Overview
3

15
CryBlock’18, June 15, 2018, Munich, Germany Selimi.et al.
min/mean/max: 0.02/13.6/109.1 min/mean/max: 0.00/55.4/1736.8
1.0 1.0
Ordering
0.9 Service
0.8 0.8
RPi 1 MelciorPalau
0.7 UPC-Portal RPi 2 RPi 3
0.6 0.6 CanBruixa
ECDF

ECDF
0.5 UPC-Alix

0.4 0.4
Pisuerga Nevaristoar RPi 6
0.3
0.2 0.2
RPi 5
GS26gener
0.1
0.0 0.0 RPi 4

1 10 100 #1
10 - 3 10 - 2 10 - 1 10 0 10 1 10 2 10 3
Link throughput [Mbps] (log10 scale) Link traffic in the busy hour [kbps] (log10 scale) BCN-Salou RPi 9
GSgV-rb

Figure 2: Bandwidth ECDF Figure 3: Traffic ECDF UPC-EETAC

JardinBotanic

RPi 10 Ethernet
RPi 8
Wireless
RPi 7

The qMp firmware has enabled to deploy several mesh

networks with actual end-users (e.g., more than 250 active lo- Figure 4: Topology of the deployed nodes
cations, typically households) in several parts surrounding the
6
city of Barcelona . At the time of this writing, there are 10 dif-
ferent mesh networks, and the largest (Sants-UPC or QMPSU)
4.1 Experimental setup
7
has 85 operational nodes. In that network, there are two gate- In our experiments, we deploy a HLF blockchain network
ways that connect the QMPSU network to the rest of Guifi.net consisting of a single organizational entity. All the transactions
and the Internet. Users join the mesh by setting up outdoor happen among the members of this single organization. The
routers (i.e., antennas) that automatically establish router- HLF components, namely peer (we deploy multiple instances
to-router links. The outdoor routers are connected through of this component), orderer, and client are deployed in different
Ethernet to an indoor AP (access point) as a premises network RPi3 boards connected to each other in the same local network.
where the edge devices and services are running: home-servers The RPi3 boards have 1.2GHz 4 core ARM cortex A53 pro-
such as Raspberry Pi’s or Cloudy devices [4]. cessor, a RAM memory of 1GB and run raspbian-stretch OS.
Network performance: We monitored the QMPSU mesh Both, in the lab and in the QMPSU network, we performed
network for a period of one month. We took hourly captures experiments by placing different HLF components at different
from the network for the entire month of March 2018. Figures physical (RPi3) nodes and by varying the number of peers
2 and 3 depict the bandwidth and traffic distribution of all the from 1 to 4. We evaluate the setup in the lab and in QMPSU
links in the network. Figure 2 shows that the link throughput network by comparing transaction latency of HLF when 100
can be fitted with a mean of 13.6 Mbps. At the same time transactions are initiated serially and in parallel. We also eval-
Figure 2 reveals that 60% of the nodes have 10 Mbps or uate transaction latencies in HLF for a 2 peer setup when the
less throughput. Figure 3 demonstrates that the maximum block size is varied from 10 to 100 transactions per block. Our
per-link traffic in the busiest hour is 1736 kbps. We observed experiments comprise of 3 runs (taken in different time slots)
that the resources are not uniformly distributed in the network. and the presented results are averaged over all the runs.
There is a highly skewed bandwidth and traffic distribution.
Node deployment: Based on the network measurement 4.2 Results
analysis we strategically deployed 10 Raspberry Pi (RPi3) 4.2.1 Transaction latency. Table 1 lists the transaction
devices on the outdoor routers to cover the area of the QMPSU completion time (referred to as Time-to-Commit (TCC))
network as presented in Figure 4. We use our previous work for 100 transactions, initiated in parallel, between the two
[13] on service placement to determine nodes in the network. peer nodes in the lab environment and in the QMPSU
In this set, we cover nodes with different properties: with network respectively with block sizes ranging from 10 to 100
higher bandwidth [13], nodes that are highly connected (i.e., transactions per block. It can be observed that, as the block
with high degree centrality) [7], nodes acting as bridges (with size increases, the transaction completion time increases both
high betweenness centrality), and nodes not well connected. in the lab setup as well as in the QMPSU network.
After the nodes were chosen, we deployed 10 RPi boards in
the community users home. Block Size TTC(Lab) TTC(QMPSU) # of Txs
10 33.4 s 64.2 s 100
4 EVALUATION 20 35.0 s 69.7 s 100
We setup a blockchain testbed network comprising RPi3 50 39.2 s 75.3 s 100
boards, each running a component of Hyperledger Fabric (HLF) 100 45.3 s 84.8 s 100
in the QMPSU network. In this testbed, different RPi3 nodes Table 1: Transaction delivery time (parallel transactions)
run different components of HLF (see Section 2.1 for details on
HLF components). In parallel, we also deployed a similar setup
in the lab environment (for performance comparison purposes) Transaction latency is defined as total time taken to endorse
and evaluated the performance in both environments. and to commit a transaction to the ledger. Figure 5 shows the
6 7
http://dsg.ac.upc.edu/qmpsu https://github.com/anirudhkabi/HLF
4

16
Towards Blockchain-enabled Wireless Mesh Networks CryBlock’18, June 15, 2018, Munich, Germany

comparison of transaction latency observed for two different

placements of HLF ordering service. We measured the transac- 24% 24%
26.3%
tion latency when the HLF ordering service is placed randomly 30.8%

in the network (Random) and when it is placed at the node

chosen with a heuristic that considers the node with higher
bandwidth and degree centrality (BASP) [13]. The results of
Figure 5 are obtained when a client initiates 100 transactions se-
quentially. This Figure reveals that the gain brought by BASP,
for the case when we have one endorser in the network, is 30.8%.
For the case when we have four endorsers in the network, the
gain of BASP over Random is 24%. Further, Figure 5 demon-
strates that in the QMPSU network it takes 1.2 seconds for
a single transaction to be appended to the distributed ledger.

4.2.2 Resource consumption. Figure 6 shows CPU utiliza- Figure 5: Transaction latency (QMPSU)
tion by various components of the HLF network namely: an
orderer, a client and two peers (an endorser and a committer).
CPU utilization of all nodes is monitored for a time period
of 60 seconds during which 100 transactions are initiated in
parallel (by the client) and all the transactions are completed.
100 parallel transactions took around 40 seconds to complete.
We chose to monitor the nodes for a time period of 60 seconds
to show idle phase usage and busy phase usage of each node.
In the graph, transactions are initiated at 11th second and
all the transactions get completed at 50th second. It can be
observed that the endorser is the node with the highest CPU
utilization whereas the orderer utilizes the least of CPU.
The Figure 6 shows that, for 100 transactions initiated at the
same time, the endorser’s maximum CPU utilization reaches
96%. The maximum CPU utilization is 81% for the committer
while it is 71% for the orderer. The reason that the endorser has
the highest CPU consumption, among other HLF components,
is because of the chaincode execution at the endorsing peer,
which does not happen at the committer and the orderer.
In HLF each component usually runs in it own Docker
8 Figure 6: CPU and memory utilization
container . The chaincode container executes the chaincode
for each incoming transaction which is something that does not
happen at the committer node. When multiple transactions usage increases during transaction execution as the execution
take place in parallel, concurrent execution of the chaincode of a chaincode also takes place at the same time. The memory
happens for all transactions thus, in turn, increasing the load usage by the endorser is about 60% during the idle phase and
on the endorsing peer. With 100 parallel transactions, we ob- reaches to a maximum of 65% during the chaincode execution.
serve that the CPU load reaches 96% at the endorser. However,
the load on each endorser can be reduced by deploying multiple 4.3 Discussion
endorsers in the network. The load on different endorsers can As we observed in our experiments that, in terms of resource
be balanced by designing a suitable endorsement policy and consumption, the endorser nodes can prove to be a bottleneck.
devising a strategy at the client to request endorsements from We believe that this bottleneck is because of the execution of
different set of endorsers each time a transaction is initiated. an additional chaincode container at each endorsing node. In
Similarly, memory usage is the highest by the endorser and our current study we only considered one endorser node to
the least by the orderer. Memory usage of committing peer falls study the resource utilization with a simple endorsement pol-
in between of endorsing peer and the orderer. At the orderer icy encoded in the corresponding chaincode. It might get more
and the committing peers, memory usage remains almost complicated when we consider more than one endorsers and
the same level between the idle phase and during transaction with a sophisticated endorsement policy. However, as discussed
execution. Memory usage at the orderer mostly falls in the in Section 4.2.2, if done right it can actually improve perfor-
range of 57%-58% while the memory usage at the committer mance. In addition to this, the actual distribution of endorsing
is in the range of 57%-60%. At an endorsing peer the memory peers in a production network, such as QMPSU, might also
affect the network performance (both in terms of CPU utiliza-
8
https://www.docker.com/what-docker tion and transaction latency). So care must be taken, specially
5

17
 CryBlock’18, June 15, 2018, Munich, Germany Selimi.et al.

in the resource constrained nature of CMNs, in designing an en- a mesh network. Future work will expand the evaluation to
dorsing policy that is also cognizant of the underlying network a wider range of hardware and network configurations and
infrastructure (i.e, topology, capacity, performance, etc). A considering real and synthetic transaction traces with a more
deployment strategy and an apt endorsement policy balancing realistic design of an endorsement policy (chaincode).
the load on various endorsers in the network can improve the 9
https://www.parity.io/
performance of the blockchain network and allow scaling of
the blockchain network without forming a bottleneck. ACKNOWLEDGEMENTS
This work is supported by the AmmbrTech Group, the
5 RELATED WORK
Ammbr Foundation, and the Spanish government project
The study [12] compares the public blockchain with permis- TIN2016-77836-C2-2-R. The authors would like to thank the
sioned blockchain and discusses the trade-offs among decentral- people from the Guifi.net (QMPSU) community network for
ization, scalability and security in the two approaches. Sousa hosting the servers and supporting the experiments.
et al. [14] present the design, implementation and evaluation
of a BFT ordering service for Hyperledger Fabric based on the REFERENCES
the BFT-SMART state machine replication/consensus library. [1] Akyildiz, I. F., Wang, X., and Wang, W. Wireless mesh networks:
Their results show that Hyperledger Fabric with their order- a survey. Computer networks 47, 4 (2005), 445–487.
[2] Androulaki, E., et al. Hyperledger Fabric: A Distributed Oper-
ing service can achieve up to ten thousand transactions per ating System for Permissioned Blockchains. ArXiv e-prints (Jan.
second and write a transaction irrevocably in the blockchain in 2018).
half a second, even with peers distributed over different conti- [3] Baig, R., Dalmau, L., Roca, R., Navarro, L., Freitag, F., and Sathi-
aseelan, A. Making community networks economically sustainable,
nents. The Blockbench [8] is a framework for analyzing private the guifi. net experience. In Proceedings of the 2016 workshop on
blockchains. It serves as a fair means of comparison for different Global Access to the Internet for All (2016), ACM, pp. 31–36.
platforms and enables deeper understanding of different system [4] Baig, R., Freitag, F., and Navarro, L. Cloudy in guifi.net: Es-
tablishing and sustaining a community cloud as open commons.
design choices. They use Blockbench to conduct comprehensive Future Generation Computer Systems (01/2018 2018).
evaluation of three major private blockchains: Ethereum, Par- [5] Belli, L. Community networks: the internet by the people, for the
9 people, 2017.
ity and Hyperledger Fabric. Their results demonstrate that [6] Cerdà-Alabern, L., Neumann, A., and Escrich, P. Experimental
these systems are still far from replacing the current database evaluation of a wireless community mesh network. In Proceedings
systems in traditional data processing workloads. In contrast of the 16th ACM International Conference on Modeling, Analysis
and Simulation of Wireless and Mobile Systems (New York, NY,
to most of the works mentioned in this section, we specifically USA, 2013), MSWiM ’13, ACM, pp. 23–30.
consider the implications of deploying the blockchain paradigm [7] Coimbra, M. E., Selimi, M., Francisco, A. P., Freitag, F., and
Veiga, L. Gelly-scheduling: Distributed graph processing for service
to a, still in use, production environment such as that of CMNs. placement in community networks. In 33rd ACM/SIGAPP Sym-
posium On Applied Computing (SAC 2018) (Apr. 2018), ACM.
6 CONCLUSION [8] Dinh, T. T. A., et al. Blockbench: A framework for analyzing
private blockchains. In Proceedings of the 2017 ACM International
The missing ingredient for widespread adoption of CMNs has Conference on Management of Data (New York, NY, USA, 2017),
always been the issue of economic sustainability. In this paper, SIGMOD ’17, ACM, pp. 1085–1100.
[9] ITU. International Telecommunications Union, ICT
we take on the issue of addressing trustworthy economic Facts and Figures 2016. http://www.itu.int/en/ITU-
sustainability by proposing the need for an economic substrate D/Statistics/Documents/facts/ICTFactsFigures2016.pdf.
built using blockchain that can keep a record of the transac- [10] Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system.
[11] Neumann, A., López, E., Cerdà-Alabern, L., and Navarro, L.
tions related to the contributions (of nodes, links, Internet Securely-entrusted multi-topology routing for community networks.
gateways, maintenance) and consumption of communication In 2016 12th Annual Conference on Wireless On-demand Network
Systems and Services (WONS) (2016), IEEE, IEEE.
network’s resources in a decentralized and trusted manner. The [12] Scherer, M. Performance and scalability of blockchain networks
evaluation of the Hyperledger Fabric blockchain deployment and smart contracts. Master’s thesis, UmeÃě University, Depart-
in the laboratory and in a real production mesh network gives ment of Computing Science, 2017.
[13] Selimi, M., Cerdà-Alabern, L., Freitag, F., Veiga, L., Sathiasee-
us an understanding of the performance, overhead, influence of lan, A., and Crowcroft, J. A lightweight service placement ap-
the underlying network, and limitations of this framework. The proach for community network micro-clouds. Journal of Grid
results show critical aspects that can be optimized in a Hyper- Computing (Feb 2018).
[14] Sousa, J., Bessani, A., and Vukolić, M. A Byzantine Fault-Tolerant
ledger Fabric deployment, in the perspective of CMNs, where Ordering Service for the Hyperledger Fabric Blockchain Platform.
several components can prove to be bottlenecks and therefore ArXiv e-prints (Sept. 2017).
put a limiting effect on the rate of economic transactions in [15] Wood, G. Ethereum: A secure decentralised generalised transaction
ledger. Ethereum Project Yellow Paper 151 (2014), 1–32.

18

View publication stats