A Delay-Tolerant Payment Scheme Based on the Ethereum...

2169-3536 (c) 2018 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. Seehttp://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI10.1109/ACCESS.2019.2903271, IEEE Access

Digital Object Identifier

A Delay-Tolerant Payment SchemeBased on the Ethereum BlockchainYINING HU1,2,AHSAN MANZOOR3,PARINYA EKPARINYA4,MADHUSANKALIYANAGE3,5,KANCHANA THILAKARATHNA4,GUILLAUME JOURJON1, AND ARUNASENEVIRATNE21Data61-CSIRO, Australia (e-mail: [email protected])2University of New South Wales, Australia (e-mail:[email protected])3University of Oulu, Finland (e-mail: [email protected])4University of Sydney, Australia (e-mail: [email protected], [email protected])5University College Dublin, Ireland (e-mail: [email protected])

Corresponding author: Yining Hu (e-mail: [email protected]).

ABSTRACT Digital banking as an essential service can be hard to access in remote, rural regions wherethe network connectivity is unavailable or intermittent. Payment operators like Visa and Mastercard oftenface difficulties reaching these remote, rural areas. Although micro-banking has been made possible byShort Message Service (SMS) or Unstructured Supplementary Service Data (USSD) messages in someplaces, their security flaws and session-based nature prevent them from a wider adoption. Global-levelcryptocurrencies enable low-cost, secure and pervasive money transferring among distributed peers, but arestill limited in their ability to reach people in remote communities.We propose a blockchain-based digital payment scheme that can deliver reliable services on top of unreliablenetworks in remote regions. We focus on a scenario where a community-run base station provides reliablelocal network connectivity while intermittently connects to the broader Internet. We take advantage ofthe distributed verification guarantees of Blockchain technology for financial transaction verification andleverage smart contracts for secure service management. In the proposed system, payment operators deploymultiple proxy nodes that are intermittently connected to remote communities where local blockchainnetworks, such as Ethereum are composed of miners, vendors and regular users. Through probabilisticmodelling, we devise design parameters for the blockchain network to realise robust operation over thetop of unreliable network. Furthermore, we show that transaction processing time will not be significantlyimpacted due to network unreliability through extensive emulations on a private Ethereum network.Finally, we demonstrate the practical feasibility of the proposed system by developing NFC (Near FieldCommunication) enabled payment gateways on Raspberry-Pis, a mobile wallet application and miningnodes on off-the-shelf computers.

INDEX TERMS Blockchain, Delay-Tolerant Network, Digital Banking, Remote Regions.

I. INTRODUCTION

INTERNET access has evolved to be one of basic needsof humans primarily due to the variety of over-the-top

services delivered through Internet. In fact, by June 2017,51% of global population had access to basic Internet [1]and nearly one billion users to high-speed fixed broadbandInternet [2]. Nevertheless, there are still more than fourbillion people, mostly in developing regions, who do not haveaccess to or can only intermittently connect to the broaderInternet [3]. This has led to the development of distributednetworking techniques, such as ad-hoc networks and delay-tolerant networks that utilize the opportunistic connectivity

to provide some level of service in the past [4], [5]. An-other proposed solution for remote regions is Community-Run Base Stations (CBSs) for local-area connectivity, forexample, Nokia Kuha base stations [6] and Telstra smallcells [7] that enable connectivity to the broader Internet viaSatellite connectivity. However, both these approaches do notguarantee the connectivity at all time.

In spite of these network irregularities, the ubiquitousavailability of connectivity is taken for granted in the de-velopment and management of many services such as fi-nance, entertainment, or health-care. As a result, customersof digital services and businesses in rural areas often face

VOLUME 4, 2016 1



operational challenges associated with network connectivity,mainly due to the lack of robustness in digital service designand management. For example, none of the popular onlinepayment schemes, including credit cards, will work wellin these connectivity-restricted environments. Since all ofthese services rely on real-time verification and processingfor security purposes. In fact, Tapscott et al. [8] estimatedthat nearly two billion people worldwide still do not haveaccess to basic banking services. Despite the paramountimportance of online banking for economic growth, littlehas been done to deliver banking services to connectivity-restricted environments, due to the inability to meet the secu-rity requirements locally without connecting to the centrallycontrolled databases [9], [10].

Cryptocurrencies have received significant attention inrecent years and are known for their ability to distribut-edly verify transactions [11], [12]. The technology behind,Blockchain, is achieved by hard-coded software programsand enables peer democracy to settle transactions. However,like most other pervasive services of today, cryptocurrenciesalso require continuous network connectivity to constantlyexchange large volumes of data among the collaboratorsof the service. For instance, a typical Bitcoin client usesaround 200 MB of data per hour [13] while the Ethereumblockchain size surpassed Bitcoin in June 2017 [14]. More-over, partitioning of the network due to interruptions in-creases the chances of malicious activities and hinder thesecurity guarantees of the blockchain [15]–[18]. As a result,cryptocurrency-based solutions in its current form do notsupport to provide online banking services for connectivityrestricted environments.

In this paper, we take advantage of distributed verificationguarantees of Blockchain technology to design a novel digitalpayment system that can be deployed over the top of anetwork with a very low quality of service guarantees. Ourfocus is at remote rural villages with community-run basestations such as Nokia Kuha [6] that are connected to thepublic Internet via unreliable satellite links. We proposean Ethereum-blockchain-based local transaction verificationscheme for online payment operators such as VISA andMasterCard and also leverage smart contracts for servicemanagement.

The paper makes the following contributions:• The design of a low-cost and secure digital payment

scheme based on a private Ethereum blockchain.• The use of smart contracts for payment service man-

agement such as user account initiation, interactionswith credit operator and management of rewards forblockchain miners.

• Probabilistic modelling of the proposed system to deviserobust design parameters for ensuring reliable func-tionality under regular as well as extreme operatingconditions. Furthermore, we show that transaction pro-cessing is highly related to block creation, and with asufficient block size, transaction arrival rate does notaffect transaction processing time.

• Through extensive emulations on a private Ethereumplatform, we show that network unreliability would notslow down transaction processing due to Proof-of-Work(PoW) difficulty adjustment and also the average blockgeneration time is relatively stable even with unreliableavailability of miners.

• Demonstrates practical viability of the proposed systemthrough a prototype implementation of NFC (Near FieldCommunication) enabled payment gateways on Rasp-berry Pis and a mobile wallet on an off-the-shelf mobiledevices.

The remainder of the paper is organized as follows: Sec-tion II provides background information on CBS, micro-payment systems. Section III describes the system architec-ture and Section IV presents models of the system design, fol-lowed by Section V that validates of our models and evaluatesour solution over a local blockchain deployment. Section VIdemonstrates a prototype implementation with multiple testresults. Section VII discusses the related work. Section VIIIhighlights insights on future directions and finally Section IXconcludes the paper. Additional key technical details ofEthereum blockchain are provided in Appendix A.

II. BACKGROUNDIn this section, we introduce the concept of CBSs and existingsolutions to deliver digital banking to remote regions.

A. COMMUNITY-RUN BASE STATIONS (CBS)Despite the advances in mobile technology, almost all coun-tries still have disconnected rural areas where the mobilecoverage is not available. Most mobile operators are reluctantto provide service to these areas due to various reasons suchas limited roadway connectivity, high maintenance cost, lackof security for infrastructure, inability of secure return ofinvestment.

To provide connectivity for such areas, operators are nowusing CBSs that can be operated by anyone in the rural area.A CBS requires a limited backhaul connectivity, which forexample can be achieved via a satellite link. CBSs are beingdeployed in various countries and regions such as Europe[19], South America [20], and Australia [7]. Nokia is alreadybuilding and selling the Kuha Mobile Network [6] around theworld.

B. DIGITAL BANKING IN REMOTE REGIONSTo reduce the service cost and enable payments that involvevery small sums of money, a number of micro-paymentschemes were proposed. Some of them leverage SMS orUSSD of the cellular networks, for instance, the Bank forAgriculture and Agricultural Co-operatives (BAAC) in Thai-land [9] and the M-Pesa Service in Kenya [10]. However,SMS messages are easily spoofable and hence require ad-ditional user verifications for security, and USSD could beaffected by session time-outs. Other micro-banking systemsare the early-generation token payment platforms securedby time-lock puzzles, e.g. PayWord and MicroMint [21].

2 VOLUME 4, 2016

IBM also proposed a Micro-iKP protocol for frequent micro-payments [22] using “coupons" sent between players andverified by the bank. This scheme however, increases thecommunication cost.

III. SYSTEM ARCHITECTUREThe primary objective of the proposed architecture is toenable cheap, cashless payments for remote villages that haveintermittent Internet connectivity. We consider the scenariowhere local network operators provide wireless coverageswithin remote communities, using technologies similar toNokia Kuha [6]. The backhaul connection to/from outsideof the communities is a low-bandwidth connection, e.g., asatellite link, that does not provide robust service guarantees.

We denote a set of payment operators as O ={o1, o2, o3, . . . }, of which each oi controls a set of proxynodes, Pi = {pi1, pi2, pi3, . . . }. The proxy nodes eachconnects a corresponding village in Vi = {vi1, vi1, vi1, . . . }via the backhaul connection. As the village networks are rel-atively isolated, we propose to deploy blockchains for trans-action processing in that they can be operated by individualswithout any centralized authority. Our scenario also fits in theconditions of a public-permissioned blockchain accordingto the guidelines provided by Wust et al. [30]. For localblockchain deployment, we propose to use Ethereum [23] forits fast, decentralised consensus and verification guarantees.The village blockchains are independent from each other andoperate on different Tokens.

As illustrated in FIGURE 1a, the proposed framework en-ables Regular Users or Customers to perform cashless finan-cial transactions with Vendors in the village irrespective ofthe connectivity to the proxy. In addition, some villagers canparticipate in the decentralised verification and become Min-ers. Regular users can join the service by simply installing amobile application on their personal devices, which operatesa blockchain light node as shown in Figure 1b. Vendors andminers will be required to have additional hardware to runfull nodes and mining nodes respectively. The proxies arefull nodes themselves to avoid creating forks when rejoiningthe village blockchain. The proxy nodes continue to operateregardless of the condition of backhaul connection. Thereis no restriction on users joining the system. The accountmanagement and mining reward distribution are operated byproxies. Instead of the default Ether generation scheme, wepropose to use a Token-based local currency to avoid inflationin the local economy.

The integration of Smart Contracts for admission con-trol and the Token based service management is unique asit automatically imposes restrictions on users entering thesystem and makes it easier for the payment operators tomanage user accounts, even when local blockchain networkis disconnected from the proxy node.

A. TRANSACTION FLOWFIGURE 1b illustrates transaction flows of the proposedframework. There are two types of transactions associated

Rural Village 1

Satellite

Mobile Operator Internet

Regular User/ Customer

Miner

Satellite

Low Bandwidth Intermittent Backhual Connection

Miner

Vendor Vendor Regular User/ Customer

Rural Village 2

Regular User

Miner

Vendor

Bank 1 Bank 2

Cashless Payment Operator

(a) System architecture.

Regular User 1

Fiat Digital

Vendor 1

Fiat Digital

Account Management Contract

Villa

geL U

F V

𝑡𝑥#,#

Block # i

Block # i+1

Block # i+2

B

RegularUser 1

Vendor 1

𝑡𝑥%,#

Miner 2

Miner 1M U

M V

Proxy Node

① ②

Account/balance validation

F P

Light Node

L

Regular User

U

Bank

B

Miner

M

Full Node

F

Vendor

V

Proxy

P

(b) Transaction flows.

FIGURE 1: Overview of the proposed system.

with regular users: i) regular transactions (txP,P ) betweenregular users and vendors, and ii) currency exchange trans-actions (txB,P ) for converting real money (fiat currency) toTokens. To perform a regular transaction, every regular userfirst needs to load their digital wallet (associated with themobile app) with Tokens. As shown in FIGURE 1b, oncevalidated by a bank, the proxy issues a transaction txB,P ,which is picked up by Miner 1 and included in Block #i.Once txB,P is confirmed, the code inside the ManagementContract is triggered and Regular User 1’s Token account isupdated accordingly as shown in Step 1©. Next, Regular User1 sends Vendor 1 a transaction txP,P to obtain the service,which is collected by Miner 2 and confirmed in Block #i+1.Each regular transaction is treated equally, processed andauthorised by the blockchain miners irrespective of the proxynode’s presence. During the proxy’s next synchronization,once it reaches Block #i+1, the smart contract is executedlocally and the Token accounts of both Regular User 1 andVendor 1 are updated as shown in Step 2©. The proxy alsocreates two accounts for itself, just like other blockchainnodes.

If an outside party without Tokens wants to make trans-

VOLUME 4, 2016 3



actions with people in the village, it first submits a requestto the proxy. Upon validation, the proxy node converts thepayment to the Token currency locally and redirects it to thetarget receiver. When Regular User A in Village A initiates atransaction with Vendor B in a Village B, Proxy A in VillageA receives the request and notifies Proxy B in Village B, whosettles the transaction in Village B and confirms with ProxyA. If Regular User A moves to Village B, she has to exchangenew Tokens for spending in Village B as a unique Token isdesignated to each individual village.

B. SMART CONTRACT BASED SERVICE MANAGEMENTTo avoid creating forks during disconnection, the paymentoperators deploy passive full nodes (cf. Part ??) as proxies.To track and manage the system operation, the paymentoperators create a smart contract, i.e. the Management Con-tract, to record account types, user balances in both fiatcurrency and Token currency, as well as distributing miningrewards. The proxy gets notified via the smart contract whena new user joins the system or when miners find blocks, andaccesses the latest version of the ledger when it is connected.States in the smart contract are constantly updated regardlessof the network condition between the village and the proxy.When connection is established, the proxy synchronises withother blockchain nodes, updates user balances and processescurrency exchange requests by issuing currency-exchangetransactions (txB,P in FIGURE 1b).

The user struct maps user type and balance to the addressof the registering user. (cf. Algorithm 1) Users registerthemselves to the system by calling the registerUser method,which notifies the proxy node. Whenever the registerUsermethod is called, an event containing the user address andthe user struct is sent along with the notification. A usercalls the sendToken function for internal transfers of Tokenwithin the village and user balance is tracked via the Balancefunction call. The createToken function call initializes thecontract with initial supply Tokens to the contract creator, i.e.the proxy. During synchronization, for each new block, theblockReward function transfers reward to the miner accounts.Token conversion is performed via convertToken.

IV. SYSTEM MODELLING AND DESIGNWe first probabilistically model transaction processing of thelocal blockchain system and the synchronization delay ofthe proxy node. We also model the overall deployment andoperational costs of one such system and use the models todesign system properties to enable an efficient and reliablelocal area payments under the given network constraints.

A. ASSUMPTIONSWe make the following assumptions without loss of general-ity:

1) All individual mining nodes have equal and stablecomputational power.

Algorithm 1: Management Contract

mapping (address => user)userListInit: struct {

string typeuint256 balance

} userEvent registerUser(Requester, user);Function registerUser(Requester, userType):

users[Requester].type = userTypeusers[Requester].balance = 0;

Function sendToken(Sender,Receiver, Amount):if balanceOf[Sender] > Amount then

balanceOf[Receiver] += AmountbalanceOf[Sender] -= Amountreturn TRUE

elsereturn FALSE

end

Function Balance(Requester):return balanceOf[Requester]

Function createToken(InitialSupply):balanceOf[Owner] = InitialSupply

Function convertToken(Requester, Amount):if balanceOf[Requester] > Amount then

balanceOf[Requester] += AmountbalanceOf[Owner] -= Amountreturn TRUE

elsereturn FALSE

end

Function blockReward():balanceOf[Blockgenerator] += 1

2) Block size is sufficient to include all transactions forimmediate processing as the transaction rate within avillage can be considerably lower compared to publicEthereum blockchain.

3) Zero transaction fees and no rewards for mining staleblocks as in the proposed system rewarding is con-trolled by the payment operator using Tokens.

4) Network bandwidth available within the village is suf-ficient for all blockchain related data traffic.

B. MODELLING TRANSACTION PROCESSINGRegular transaction arrival rti , where ti is the transactioninitiation time, follows a Poisson distribution as observed in[31]. We denote the average arrival rate as λt transactionsper second (tps). Block generation time T has been shown to

4 VOLUME 4, 2016



be exponentially distributed with probability density functionG(T ) = λe−λT , where λ = 1

E[T ] [26]. In Ethereum,the expected block time E[T ] ≈ 12s. Since we assumeblock size to be large enough (cf. assumption 2), there areno pending transactions as all new transactions arriving inthe current mining session are included in the next block.Therefore, transaction processing time tp = T − ti, whereti, tp ∈ (0, T ]. We further analyze the distribution of blocktime and transaction processing time under different arrivalrates in Section V-B. Transaction throughput can also becalculated as

∑∀ti≤T rtiT . With transaction size being st bits,

a block needs to accommodate sb = st∑∀ti≤T rti bits

of regular transactions, averaging s̄b = λtstE[T ] bits overmultiple sessions.

There are currency-exchange transactions with the proxyfull node when it is connected. We model currency-exchangetransaction arrival eti similar to regular transactions withaverage arrival rate λe and size se. With these transactions,a block size is s′b = st

∑∀ti≤T rti + se

∑∀ti≤T eti , with the

average being s̄′b = (λtst + λese)E[T ].

C. MODELLING THE SYSTEM COSTWe derive cost models from the payment operators’ pointof view for mining rewards and system operation using themetrics in [32]. We omit transaction validation and storagecosts in our calculations as they are only a small fraction ofmining equipment cost and mining itself [32].

1) Rewarding Cost

Although the block reward is an incentive for miners, it is anextra cost for the payment operators. We use R to denote theblock reward, meaning that a payment operator has to spendR Tokens for each valid block. We calculate the rewardingcost as CR = nR, where n is number of blocks.

2) Network Resources

Since we assume ideal network conditions (cf. assumption4) locally, we only model the network resource usage of thebackhaul network. When connected, the proxy full node syn-chronizes past transactions and processes money exchangerequests. We define one service period as TS = TC + TU ,where TC and TU stand for the durations of connection anddisconnection respectively.

We denote the backhaul network bandwidth requirementasBW and cost asCBW in Token per bit. Then, the expectednetwork connectivity cost would be CN = CBWTCBWduring one service period.

3) System Cost

To sum up, the overall system cost to the payment operator isthe sum of all the aforementioned costs. Since cost compo-nents are defined with different time units, we calculate theoverall cost within time period T0, which equals xb blocksand xs service periods as:

CAll = CR + CNxs = Rxb + CBWTCBWxs. (1)

D. MODELLING THE PROXY NODE SYNCHRONIZATIONRegular transactions arrive when the proxies are con-nected via the back-haul link and when disconnected, whilecurrency-exchange transactions only occur when the prox-ies are disconnected. We here assume the connection anddisconnection periods to be much longer than block time.We use nU (

∑nU

i=1 Ti = TU ) and nC (∑nC

i=1 Ti = TC)to represent number of blocks created when connected anddisconnected respectively. Transactions committed duringone disconnected period can add up to a total size of sU .Substituting the block size derived in Part IV-B, we obtain,

sU =

nU∑j=1

sbi =

nU∑j=1

st(∑∀ti≤Tj

rti)

= st

nU∑j=1

∑∀ti≤Tj

rti = st∑∀ti≤TU

rti ≈ λtstTU

(2)

We do not consider network delay or communicationoverhead when the proxy node establishes connections withthe village network. We use t as the time passed since thebeginning of the connection and denote data remaining to besynchronized as sr,

sr = sU + (st∑∀ti≤t

rti + se∑∀ti≤t

eti)−BWt

≈ sU + (λtst + λese)t−BWt

(3)

When new transactions arrive, synchronization only fin-ishes when the connection closes. When BW is big enough,there exists a time t0 (t0 ≤ TC), from which data remainingto be synchronized reaches 0, i.e., sr = sU + (λtst +λese)t0 −BWt0 = 0. Hence,

t0 =sU

BW − (λtst + λese). (4)

To find the range of BW that satisfies Equation 4, we lett0 ≤ TC , i.e., sU

BW−(λtst+λese)≤ TC , from which we obtain

BW ≥ (λtst + λese) + sU/TC . (5)

When BW is small, i.e., BW < (λtst + λese) + sU/TC ,there will always be data left when connection closes. Overtime new transactions accumulate and the proxy node cannotaccess the latest version of the ledger.

E. MINING NETWORK DESIGNWe now find ranges of multiple mining network parametersincluding number of miners and their connectivity to ensurereliability and security.

VOLUME 4, 2016 5



1) Miner OutagesMiners are incentivized to work, but they may join orleave the network spontaneously (churn) [33]. We denotethe total number of online miners as lon, lon ≤ lm. Theprobability of one miner going offline in each time slot isp1, p2, p3, · · · , plm . Hence the probability thatX = k minersare offline in the same time slot can be represented by aPoisson Binomial Distribution:

Pr(X = k) =∑A∈Fk

∏i∈A

pi∏j∈Ac

(1− pj), (6)

where the set Fk contains all subsets of k integers thatcan be selected from {1, 2, 3, · · · , lm}, and A and Ac arecomplementary. If all miners have the same chance of goingoffline, i.e. p1 = p2 = p3 = · · · = plm = pd, the expectationof lon is:

E[lon] = lm − E[X] = lm(1− pd), (7)

or equivalently,

lm =E[X]

pd=E[lon]

1− pd. (8)

We demonstrate how network churn affects the blockchainsystem performance in Section V-C.

2) Mining RewardPayment operators determine the mining rewardR accordingto the status of local economy and its budget. It becomesharder for each individual miner to find a valid block whenthere are more competitors (cf. assumption 1). As the ex-pected reward reduces, mining becomes less profitable. Wecalculate the minimum mining reward needed to keep minersincentivized. We denote the mining cost as η per hash, similarto [34]. With individual hash rate being h, each miner’soperational cost per second is ηh. The expected hash cost ofthe entire network per second CH when all miner are online(worst case) is CH = lmηh. Since miners are equal, theirexpected revenue per mining round isR′ = R/lm. We do notconsider rewards provided for stale blocks (cf. assumption3). We derive the expected profit per mined block for eachindividual as:

Π = R′ − CHT

lm=

R

lm− ηhT. (9)

Clearly, for mining to be profitable, Π should be greater than0, i.e., R should satisfy:

R > lmηhT. (10)

3) Minimal Connectivity RequirementA key factor of blockchains is the synchronization across thenetwork, i.e. every node should obtain a copy of the ledger.Individual miners may want to reduce their data usage byconnecting to fewer other nodes, but for security all minersare encouraged to connect to as many other peers as possible.We here provide an intuitive picture on the minimal directconnections required for efficient information propagation

across the network. For simplicity, we assume that on aver-age every miner maintains connections with lc other nodes,0 < lc ≤ lm. Once Miner A receives a transaction or a block,she sends it to all her directly connected nodes. The sameprocedure repeats until the message reaches every node inthe network. We define information propagation from onenetwork node to another as a hop. Restricting maximumnumber of hops to k, we obtain:

1 + lc + lc(lc − 1) + · · ·+ lc(lc − 1)k−1

= 1 + lc

k−1∑i=0

(lc − 1)i ≥ lm.(11)

We solve Equation 11 under given k and lm. We do not uselon as eventually all miners will store the blockchain. Weobtain γ, fraction of nodes that one should directly connectto as:

γ ≥ min (lc)

lm. (12)

F. SUMMARYAlthough the payment operators’ intention is to have fewermining nodes to reduce the equipment cost, there shouldbe sufficient miners to keep the fairness of the system. Thepayment operators should also consider real-world churnrate and network resource costs to determine the miningreward. Furthermore, all villagers, especially miners, are rec-ommended to increase their connectivity for better synchro-nization even though this leads to higher bandwidth usage.

V. EVALUATIONIn this section, we first validate our transaction processingmodel by comparing it to a real deployment of a privateEthereum blockchain and make predictions about the systembehaviour based on the validated model. We also dimensionthe local blockchain network design to satisfy the minimumaverage connection required for each mining node. Finally,we evaluate the blockchain performance under different net-work conditions on the experimental deployment.

A. EXPERIMENTAL ENVIRONMENTWe deployed a private Ethereum blockchain on multiple vir-tual machines running Ubuntu Linux v16.04 in an Openstackenvironment.1 Each virtual machine is given 1 virtual CPUcore, 2 GB of memory, and 10 GB of persistent storageto meet the minimum hardware requirement for runningEthereum. Elastic Search2 was used to store block-relatedinformation. The network behaviour was monitored using thePython Web3 Library.3

All virtual machines are linked together in a low-latencylocal network that can be customized on demand. Nodesare connected via a single Gigabit Ethernet switch and form

1https://www.openstack.org2https://www.elastic.co3https://web3py.readthedocs.io/en/latest/index.html

6 VOLUME 4, 2016

https://www.openstack.org

https://www.elastic.co

https://web3py.readthedocs.io/en/latest/index.html



0 20 40 60Time (s)

0.000

0.025

0.050

0.075

0.100

0.125

0.150

0.175

PDF

SimulationExperiment

(a) Block time.

0 20 40 60Time (s)

0.000

0.025

0.050

0.075

0.100

0.125

0.150

0.175

PDF

SimulationExperiment

(b) Transaction processing time.

FIGURE 2: Block generation and transaction processing.

a star topology similar to the cellular network shown inFIGURE 1a. With this setup, a communication round-triptime between any two nodes is less than 1 ms on average. Weemploy Linux traffic control to introduce delays to emulatethe high latencies in mobile networks and configure the Linuxkernel firewall with Iptables4 to emulate churns.

We used Geth v1.6.4 5 for all of our empirical evaluations.Before the actual experimentation, we let the system stabilizefor a few hours to obtain appropriate parameters of thegenesis block in later runs. Based on our observations, weset the initial nonce value, gas limit and difficulty to 0x42,0x08000000, 0x400000 respectively to make the system sta-bilize quickly. To form a fully connected P2P blockchainnetwork, we disabled the auto-discovery feature supported byGeth and configured the overlay network manually. Finally, ifnot mentioned otherwise, all experiments involved 10 miningnodes and 10 light nodes.

B. MODEL VALIDATION AND NUMERICAL SENSITIVITYANALYSIS1) Model ValidationTo validate our model described in Section IV-B, we emu-lated a transaction processing scenario by issuing transac-tions at 1 tps (overall rate) from multiple clients to randomlyselected addresses. We sort block timestamps in ascendingorder and calculate block generation time as the differencebetween two adjacent timestamps. To obtain transaction pro-cessing time, we record the timestamp upon initiation ofa transaction and extract the inclusion timestamp from thetransaction receipt. FIGURE 2a and FIGURE 2b present thesimulation and emulation results of 500 consecutive blocks.Both illustrate a strong agreement between modelling and ex-perimental measurements. Additionally, an inter-comparisonbetween FIGURE 2a and FIGURE 2b confirms that transac-tion processing and block generation are highly correlated.

2) Impact of Transaction Arrival RateWe then intended to empirically study the impact of trans-action rate on transaction processing and benchmark thelocal blockchain performance. However, when increasing thearrival rate, we hit the transaction sending limit before the

4https://help.ubuntu.com/community/IptablesHowTo5https://github.com/ethereum/go-ethereum

50th 70th 90th 95th 99thPercentiles

0

10

20

30

40

50

Bloc

k tim

e (s

)

0.2tps1tps5tps25tps

(a) Block time.


0

10

20

30

40

50

Tran

sact

ion

proc

essin

g tim

e (s

)

0.2tps1tps5tps25tps

(b) Transaction processing time.

FIGURE 3: Simulation with multiple transaction rates.

processing limit due to implementation flaws in the Ethereumversion we used. Indeed, with more than 3 tps, the transactiongenerator stopped working due to connection errors as thealgorithm assumes that some nodes are flooding the systemwith too many requests. Despite that the transaction generatorworked smoothly with lower arrival rates, in the end only4246 out of 17265 transactions were mined at 2 tps. We hencedecided to analytically study the system behaviour undermultiple transaction rates.

Using the validated model in Part V-B1, we further gen-erated transactions at various rates including 0.2 tps, 1tps, 5 tps, and 25 tps in our simulation. FIGURE 3a andFIGURE 3b compare the 50th, 70th, 90th, 95th and 99thpercentiles of block time and transaction processing timeunder all the simulated arrival rates. These results confirmthat with a sufficiently large block size, block creation timeand transaction processing time are not affected by the arrivalrate.

3) Proxy Node Synchronization

We simulated 50 consecutive services sessions with thedisconnection and connection in each service session beingTU = 9hrs and TC = 1hr respectively. We estimatedthe transaction size to be 200 bytes from the real-life datacollected by Blockchain.Info, and an average rate of 2 tps and1 tps for regular and currency-exchange transactions respec-tively. Figure 4a illustrates data remaining to be synchronizedby the proxy node over these 50 consecutive service sessions.We use bandwidths of 4 Kbps and 128 Kbps to show the twoscenarios discussed in Part IV-D. Indeed, under a large syn-chronization bandwidth, the proxy node can always accessall transactions by the end of a service session. When thebandwidth reduces, new transactions accumulate, making itimpossible for the proxy to catch up.

We then analyzed the synchronization when transactionsonly arrive during disconnection. We did not limit the con-nection duration and measure the time taken for a fullsynchronization averaged over 10 service sessions, with TUranging from 1 min to 10 min and TC unlimited. A distribu-tion of the synchronization times is shown in Figure 4b. Theresult with off-the-shelf devices is presented in Part VI-B1.

VOLUME 4, 2016 7

https://help.ubuntu.com/community/IptablesHowTo

https://github.com/ethereum/go-ethereum

https://www.blockchain.com



0 5 10 15 20Time (days)

0.0

0.1

0.2

0.3

0.4

0.5

0.6

Rem

aini

ng d

ata

(GB)

128Kbps4Kbps

(a) Data remaining.

2 4 6 8 10Disconnection duration (min)

0.0

2.5

5.0

7.5

10.0

12.5

15.0

Sync

hron

izatio

n de

lay

(s) 128Kbps

256Kbps512Kbps1Mbps

(b) Synchronization delay.

FIGURE 4: Simulated synchronization results.

4) Minimal Connection RequirementBased on the analysis presented in Part IV-E3, we obtainthe minimal connection requirement when varying numberof hops k from 1 to 4 in (Condition 11) with a total numberof miners lm increasing from 4 to 100. FIGURE 5 displaysthe results in the number of nodes and fraction of the net-work. Minimum lc that satisfies Condition 11 may remainunchanged for a range of lm, which results in steps or spikeson the curves. As shown in FIGURE 5a, when k = 2, witha total of 100 miners, each individual needs to maintain atleast 10 connections. When k = 3, the minimum numberof connections required reduces to 4. Generally, if only onehop is allowed for information propagation, all miners needto connect with all other miners. While if more hops areallowed, miners can reduce the number of their connectionsand save the bandwidth usage. This indicates the system’sability to scale without miners exhausting their networkresources.

0 20 40 60 80 100Total # of miners (lm)

101

102

Min

imal

con

nect

ions

(# o

f nod

es)

k=1k=2

k=3k=4

(a) # of connections.

0 20 40 60 80 100Total # of miners (lm)

10 1

100

Min

imal

con

nect

ions

(fra

ctio

n)

k=1k=2

k=3k=4

(b) Fraction of the network.

FIGURE 5: Minimal connection requirement.

C. EFFECT OF NETWORK DISTURBANCESTo further evaluate the performance of the local blockchainnetwork, we investigated its behavior under disturbancessuch as Network Delays and Network Churns. Since it wasimpossible to obtain the whole picture from transaction pro-cessing (cf. Part V-B2), we have considered block generationtime to be an alternative evaluation metric (cf. Part V-B1).

1) The (non)Impact of Network DelaysIn order to understand the stability of the proposed sys-tem when inter-node delay increases, we introduced variousdelays of 0, 10ms, 50ms, 100ms, 500ms, and 1000ms perconnectivity channel.6 FIGURE 6a shows the 50th, 70th,90th, 95th, 99th percentiles of block time, from which it ispossible to observe that the block time remains stable evenwith delays reaching 1 second. We ascribe this to PoW diffi-culty adjustment where network delay causes time differencebetween two adjacent blocks to increase, and as a resultthe internal algorithm reduces difficulty level to achieve ashorter block time. FIGURE 6b illustrates block difficultyunder multiple network delays. A decreasing trend can beobserved in the difficulty level when delay increases. Thisbehaviour helps to maintain the transaction processing speed,but is undesirable because with a fixed total network hashrate, a lower difficulty level leads to more stale blocks andinconsistencies.


0

10

20

30

40Bl

ock

time

(s)

<1ms10ms

50ms100ms

500ms1000ms

(a) Block time percentiles.

<1 10 50 100 500 1000Delay (ms)

4.2

4.4

4.6

4.8

Diffi

culty

leve

l (M

H)

(b) PoW difficulty levels.

FIGURE 6: System behaviour with network delays.

2) Network Churnsa: Transient ResponseOne of the main concerns of P2P networks is the churn rateof nodes. We emulated a scenario in which some miners gooffline at time t0 and observed variation in block creationtime. As shown in FIGURE 7, when some miners go offline,block time experiences a significant increase followed by a“resolving period” during which PoW difficulty is adjustedin response to changes in network hash rate. To find the

6Today’s mobile network delays can hardly go beyond 1 second: https://hpbn.co/mobile-networks/

8 VOLUME 4, 2016

https://hpbn.co/mobile-networks/

https://hpbn.co/mobile-networks/



0

100

200t0 One miner down

0

100

200Two miners down

0

100

200Three miners down

0

100

200Four miners down

0 250 500 750 1000 1250 1500 1750 20000

100

200Five miners down

Time (s)

Bloc

k tim

e (s

)

FIGURE 7: Transient response to mining nodes going offline.

end point of the “resolving period”, we select the timestampfrom which the absolute variation is less than 5% for thenext 3 consecutive points. Duration of “resolving period”is measured as 361s, 781s, 577s, 527s, 969s respectively.Overall, it increases with the number of offline nodes. Whilethe network recovers, we also observed “backwards mining”,where newer blocks sometimes have smaller block numberthan older ones. The disagreement is resolved with the stabi-lization of the network.

b: Changes Over TimeWe then tested system performance when each miner has aprobability of 10%, 20%, 30%, 40% and 50% to go offline.We ran each set of experiment for approximately 2 hours andchanged miner status (online or offline) every 20 minutes.FIGURE 8 shows the 50th, 70th, 90th, 95th, 99th percentilesof block generation time, from which we can see block timedoes not vary much across all churn rates. In other words,number of miners do not affect speed of block generation ortransaction processing.


0

10

20

30

40

Bloc

k tim

e (s

)

010%

20%30%

40%50%

FIGURE 8: System steady-state behaviour with networkchurns.

3) SummaryDespite being unable to test the processing limitation due tothe shot comings of the Ethereum implementation and ob-taining all transactional data experimentally, we managed tostudy the effect of network disturbances. Difference betweenempty blocks and blocks with transactions depends on blocksize, hence the additional transmission delays which areexpected to have similar impacts to network delays. Resultsshow that delays and churns may cause block generation timeto change especially in the transient state. However, due tothe difficulty adjustment they do not necessarily slow downblock generation in the long run. Overall, the main observeddrawback of the local blockchain is that disturbances maycause more temporary inconsistencies.

VI. IMPLEMENTATIONWe demonstrate the feasibility of the system a prototype im-plementation containing a private Ethereum blockchain andan intermittently connected proxy node was implemented.We tested the synchronization delay of the the proxy nodewhen varying the bandwidth and disconnection duration. Wealso measured the usage of data, CPU, and battery of themobile wallet app using DDMS 7 and Battery Historian. 8

A. SETUPFigure 9 illustrates the setup with one full node, 2 shops,and 3 regular users. Each shop runs a mining node and inaddition, Shop 1 owns two full nodes and Shop 2 owns onefull node. Regular User 3 operates a miner while the othertwo regular users are light mobile clients. We summarize thedevice types, their capabilities and Geth versions in Table 1.

TABLE 1: Devices and their capabilities.

Miner Full node Light node

Device Dell Latitude6430u Raspberry Pi 3 Google Pixel

XL# of nodes 3 4 2

OS Ubuntu 17.04 Raspbian Jessie Android v8.0.0RAM 4GB 1GB 4GBGeth v1.6.5 v1.6.5 v1.6.7

# of miningthreads 4 - -

We used a D-Link DSR-250N Wi-Fi router connectedto the Oulu public WAN (PanOULU) [35] to emulate thecommunity base station. We used an IEEE 802.11n Wi-Finetwork to emulate the local network and interconnect theabove. The proxy node’s backhaul bandwidth via the router’sWAN port. The auto-discovery protocol of Geth was used onall nodes.

We installed an application developed in Python 2.7.12on the proxy node to update the account information. It isimplemented on a Raspberry Pi 3, which also acts as anEthereum full node. This application synchronizes with the

7https://developer.android.com/studio/profile/ddms.html8https://developer.android.com/studio/profile/battery-historian.html

VOLUME 4, 2016 9

https://developer.android.com/studio/profile/ddms.html

https://developer.android.com/studio/profile/battery-historian.html



FIGURE 9: Prototype implementation.

blockchain using the Python-JSON RPC library.9 It keepstrack of the connectivity and update the account balances inSQLite database. We have also developed a smart contract inSolidity v0.4.12 for token creation, conversion and transfer(cf. Section III).

Each payment gateway is composed of one AdafruitPN532 NFC module and a Raspberry Pi 3 attached to a touch-screen, as shown in Figure 10. After entering the amount, thevendor can select from multiple payment options. The appli-cation also synchronises with the blockchain for confirmationof token transfer. Once the payment has been confirmed inthe user wallet and a block is created, a new transaction isrecorded on the blockchain. At the same time the transactionreceives one block confirmation and the payment gatewaynotifies the vendor.

FIGURE 10: Payment gateway

For regular users, we developed the mobile wallet app (cf.Figure 11) in Android Studio 3.0. The mobile client joinsthe blockchain as a light node, which submits and retrievestransactions directly to/from the blockchain. Both NFC andQR code based payment modes are embedded in the app.After the user selects a payment method, the app asks theuser to confirm the transaction information. Once confirmed,the app signs the transaction and submits it to the Ethereumblockchain. The app also shows the account balance, recenttransaction history and can store multiple Ethereum accounts.

9https://github.com/ConsenSys/ethjsonrpc

FIGURE 11: Mobile wallet application

B. MEASUREMENTS1) Proxy Node SynchronizationWe emulated a situation where transactions are only com-mited during disconnection, as described in Part V-B3. FIG-URE 12a illustrates the average synchronization delay andvariation over 10 runs of each scenario. Compared to thesimulation results in Figure 4, the synchronization time doesnot increase proportionally with the disconnection duration,especially for bandwidths higher than 512 Kbps. This is be-cause TCP communication speed cannot reach the maximumbandwidth at the beginning of the connection. When discon-nection lasts for only a few minutes, data to be downloadedby the proxy node is small and synchronization finishesbefore TCP communication reaches its maximum bandwidth.As the disconnection duration increases, the amount of datato be downloaded also increases, TCP communication canreach a higher and more stable bandwidth during the syn-chronization, which results in the decrease in the slope of theplots.

2) Mobile Wallet PerformanceWe then measured data, CPU and battery usage of the mobilewallet in its idle state (i.e.Inactive mode) and when it sendsone transaction per minute (i.e. Active mode) for a total of onehour. Note that without sending any transactions, the mobilelight client continuously synchronizes with the network anddownloads block headers. As shown in FIGURE 12b, ourwallet app uses only 2.71 MB in total in its idle state, and anadditional 21.65 KB to perform one transaction per minute.The overall CPU usage increased from 51.9s to 127.7s withinthe one-hour period. When it comes to power consumption,the wallet used 3.2 mAh or 0.04% of the mobile phone’stotal battery usage in its idle state and 19.8 mAh or 0.11%when sending transactions. These results confirm our walletapp requires low bandwidth, CPU processing and power forits operations compared to available cryptocurrency clients[13].

VII. RELATED WORKWe categorize related work into i) Side-Chain and Off-ChainSolutions, ii) Pervasive, Delay-Tolerant Networks, and iii)

10 VOLUME 4, 2016

https://github.com/ConsenSys/ethjsonrpc



2 4 6 8 10Disconnection duration (min)

0.0

2.5

5.0

7.5

10.0

12.5

15.0

Sync

hron

izatio

n de

lay

(s) 128Kbps

256Kbps512Kbps1Mbps

(a) Synchronization delay.

Upload Download TotalData usage

0

1000

2000

3000

4000

Size

(KB)

820

1891

2702

1258

2752

4010InactiveActive

(b) Mobile wallet data usage.

FIGURE 12: Test results on prototype implementation.

Blockchain Cost Models.

A. SIDE-CHAIN AND OFF-CHAIN SOLUTIONSA number of side-chain and off-chain solutions have beendeveloped to solve the on-chain scalability problem. Themain idea is to shift part of the transactions away from themain chain. As side-chain and off-chain solutions can workindependently from the main chain, they have the poten-tial to be applied to intermittently connected environments.However, although there are implemenations like EthereumPlasma [36] and Bitcoin Lightning Network [37], the avail-able platforms are still at their early stage and are yet tobe deployed widely. For example, side-chains like Plasmaincrease complexity when it comes to data availability andblock withholding attacks. While off-chain solutions like Bit-coin Lightning lacks flexibility during channel opening andclosing. In addition, as an off-chain channel only involvestwo parties, in comparison to a public blockchain, completetrust is hard to achieve between only the two.

B. PERVASIVE, DELAY-TOLERANT NETWORKS INREMOTE REGIONSDelay-tolerant networks can be a potential solution to deliverInternet services to developing regions. Blattman et al. [38]found delay-tolerant networks are sufficient for digital ser-vices to meet the needs of most rural communities. Pentlandet al. [5] later developed DakNet that uses a pervasive mobilecoverage to enable asynchronous digital services in Indiaand northern Cambodia. DakNet is remarkably low-cost andwell-received by local users as it is more accessible than acentralised, community telephone. The success of DakNetproves that decentralization is an effective way to deliverservice to remote regions.

Taking use of a CBS, together with an intermittent con-nection with the outside to form a delay-tolerant network,we are able to deploy a blockchain system to process inter-village transactions and keep track of the transactions fromoutside. However, delays can greatly affect the security ofblockchains whose operation relys on continuous networkconnectivity when forks happen. To avoid forming disagree-ments during the disconnection, we only operate a full nodeas the proxy.

C. BLOCKCHAIN COST MODELSCroman et al. [32] did a reality check of Bitcoin and an-alyzed the cost to confirm transactions. Rimba et al. [39]later proposed cost models using parameters such as gasand gasPrice to compare Ethereum with cloud services forbusiness process execution. We stick to findings in [32] toobtain deployment and operation costs as the gas-relatedparameters can be adjustd by the bank.

VIII. DISCUSSIONAlthough the ultimate control belongs to the payment oper-ator, the reliable operation of the system is achieved via de-centralization. Compared to traditional, centralised solutions,our approach is robust against node churn and can effectivelyavoid single-point-of-failure with lower deployment cost.However, some aspects of the system design can be furtherimproved.

A. BLOCKCHAIN INEFFICIENCYPoW is a heavy consensus algorithm, and its inefficiencybecomes more significant in public cryptocurrencies. It wasnot problem in our prototype implementation. As blockchaintechnology evolves, lightweight consensus protocols are be-ing explored [40]–[43]. If it was to become a problem, thesenew protocols can be easily incorporated with the proposedsystem.

B. SECURITYIn this paper, we have demonstrated the case where there areno intended, malicious behaviors. Below we present a briefdiscussion on security based on the current literature.

1) Temporary Inconsistency (not a real threat)Even though blockchain forks or stale blocks are an importantindicator of inconsistency [26], if players behaves honestly,all conflicts can be resolved eventually. Hence, stale blocksthemselves are not a direct threat to network security. How-ever, they increase the chance of double-spend attacks thatare usually caused by disagreements within the network [28].

Countermeasure: As suggested by Karame et al. [44],double-spend attacks can be mitigated by applying a “listen-ing period" of a few seconds on the recepient side. In theproposed system, this can be integrated into the mobile walletdesign.

2) Network Partitioning (a real threat)An attacker who knows about other nodes and their connec-tions can perform routing attacks to partition the network,such as the eclipse attack performed by [16], and the balanceattack [17].

Countermeasure: Two potential countermeasures can bedeployed, one centered around the proxy and another aroundparticipating node themselfves.

In the first case, we can enable the proxy to deploy a smartcontract that tracks node connections and detects network

VOLUME 4, 2016 11



partitioning. When the proxy is connected, it accesses resultsgenerated by this smart contract. If subgraphs are detected,the proxy can take action, e.g. to force nodes in the subgraphto restart and refresh their connections as suggested by Apos-tolaki et al. [15]. Furthermore, full nodes and light nodescan also help to increase connectivity, and mitigate networkattacks. In the second one, participating nodes themselveskeep track of their own connections and changes in thenetwork topology. As for a network partitioning attack tosucceed, significant changes in the observable topology areneeded [17], if a node observes that it lost a large number ofits peers within a small timeframe, transactions can be frozenuntil the overlay network stabilizes again.

C. THE DELAYED ACTIONSLimited by the intermittent connectivity, in the current sys-tem, a user can only exchange tokens with the proxy when aconnection is available. In addition, although network data iscollected and analyzed in real time by miners, proxy controldoes not happen immediately.

IX. CONCLUSIONWe proposed a blockchain-based payment scheme for inter-mittently connected regions. As a result, we have achievedthis through a novel use of smart contracts and a token-basedadmission control, account management, and mining rewardsdistribution. Through mathematical models we analysed sys-tem dynamics and the costs for the setup and operation. Wethen validated the proposed system through prototype imple-mention on a private Ethereum testbed and demonstrated thepracticality of system design using off-the-shelf laptops andmobile devices. Finally, through a comprehensive study ofthe local blockchain operation, we showed the system stabil-ity under network disturbances and demonstrated the wholesystem operates well in resource-constrained, dynamic, inter-mittently connected environments.

In the future, we will address security vulnerabilities fur-ther and look into solutions that enable seamless operationunder network irregularities. In addition, we will explore thepotential of using the proposed management framework inother domains.

.

APPENDIX A ETHEREUM BASICSWe base our system design on the Ethereum platform [23], asit has a short block-generation time that makes it easy to gen-erate large volume of block data for analysis. A summary ofkey terminology that is required to understand the Ethereummechanisms is presented below.

A. NODES AND THEIR CONNECTIVITYA blockchain consists of a P2P communication overlay net-work. In the case of Ethereum, each network node continu-ously attempts to connect to other nodes until they have peers.By default, Ethereum nodes use a gossip protocol to findout about other nodes. Each node maintains connections to

a few peers either discovered during startup through the P2Pprotocol, or manually added using their public IP addresses.

Once the overlay network is created, nodes on a blockchainmay act as full nodes, miners or light nodes. All nodescontribute to the network connectivity and information (i.e.,transactions and blocks) propagation. Miners and full nodesverify all transactions based on their signatures and updateany state changes, and keeps a complete transaction record.In addition, miners settle transactions via a process calledmining as explained in Part A-C. Light nodes operate inthe Simplified Payment Verification (SPV) mode and onlydownload block headers and verify and store transactions thatare related to them. Table 2 summarizes node types and theircapabiities in a typical blockchain network.

TABLE 2: Summary of node capabilities.

Node Type Mining Verification StorageMiner Yes Yes Yes

Full Node No Yes YesLight Node No Partial Partial

B. TRANSACTION, BLOCK AND SMART CONTRACT

The public Ethereum blockchain works as a global statemachine, where the state is represented by peer interactionsor transactions. For simplicity and efficiency, transactionsare grouped together to be settled and immutably recordedin blocks. A user needs an Externally Controlled Account(EOA) to send and receive transactions. An EOA is linked toan ether balance and is controlled by the user’s private key.

Ethereum also uses smart contracts to automatically formagreements among different entities. Smart contracts areidentified by contract accounts, which are similar to EOAsbut are associated with “code" that can be triggered bytransactions or messages (calls) received from other EOAsor contracts. Smart contracts also have storage capabilities.The states recorded in a smart contract are updated upon avalid transaction and the messages it carries.

Transactions can be sent between two EOAs, two contractaccounts, or an EOA and a contract account. In the publicEthereum network, miners may also collect transaction feesto make a profit [23]. Transaction priority, i.e. how likely andhow soon a transaction is to be picked up by miners, dependsmostly on its value, age and the transaction fee attached.State of a blockchain is computed after every block [24], andthe code in smart contracts is executed by all nodes whensynchronization happens (cf. Part A-C).

C. THE BLOCKCHAIN

Nakamoto in his original paper proposed a PoW scheme toconfirm transactions and select representation in majoritydecision making [25]. PoW is also adopted by the currentversion of Ethereum as described below.

12 VOLUME 4, 2016



1) PoW Mining and Difficulty ControlPoW mining is essentially the process of repeatedly calculat-ing a hash value with an incrementing nonce until the hashis smaller than a target. Hashrate is the speed at which aminer computes hashes. Miners compete against each otherin solving PoW puzzles and broadcast blocks to the rest ofthe network upon block creation for validation and synchro-nization. In addition to mining, miners also listen for newtransactions and blocks discovered by others to prepare thenext block.

Difficulty is a measure of how difficult it is to solvea PoW puzzle. Difficulty adjustment over PoW puzzlesleads to a stable block creation rate. In Ethereum the cal-culation is based on the block number, timestamp of thecurrent block, and timestamp & difficulty of its parentblock. For Ethereum Homestead,10 the adjustment is al-ways a multiple of parent_diff // 2048, with pa-rameter a ∈ [−99, 1]. We denote block_timestamp -parent_timestamp as δt, and summarize the adjust-ments in Table 3. Difficulty adjustment is insignificant undera high network hashrate.

TABLE 3: PoW difficulty adjustments.

Timestamp difference Adjustmentδt < 10s a = 1

10s <= δt < 20s Difficulty unchanged, a = 020s <= δt < 1000s Adjust downwards proportional to

δt, a ∈ [−99,−1]δt >= 1000s a = −99

2) Consensus and Chain GrowthTransmission delays may lead to stale blocks, or forks [26]as multiple blocks could be created at the same time, andreceived by different nodes across the network. A block isattached to the chain once created, with its own block headerpointing to the previous block header, and all the way back tothe genesis block. All peers work out these inconsistencies byselecting the longest chain. Ethereum determines the longestchain based on the total difficulty of all the blocks.11

3) Node SynchronizationNetwork delays and node churns are common in blockchainsystems. If one node restarts after going off-chain, it enquiresits peers to obtain the latest version of the ledger. Statesstored in a particular block can only be accessed if the nodesynchronization has reached it.

D. COIN SUPPLYTo compensate the resources consumed in mining, a fixedamount of new tokens, or mining reward, is generated uponthe creation of blocks and paid to the winners. This rewarding

10http://ethdocs.org/en/latest/introduction/the-homestead-release.html11Ethereum does not implement the full Greedy Heaviest-Observed Sub-

Tree (GHOST) protocol proposed by Sompolinsky and Zohar [27], instead,it uses a longest-chain rule with rewards for stale blocks [28].

scheme is necessary as it makes the blockchain more secure[29], but the continuous creation of coins may result ininflation.

ACKNOWLEDGMENTThis work is performed under the framework of RESPONSE5G (Grant No: 789658) project European Union and 6Gene-sis Flagship (grant no. 318927) project funded by Academyof Finland.

REFERENCES[1] “Global Internet Usage.” https://en.wikipedia.org/wiki/

Global_Internet_usage, 2018, [Online; accessed 11-April-2018].[2] “Number of fixed broadband internet subscriptions worldwide from

2005 to 2017 (in millions),” https://www.statista.com/statistics/268673/number-of-broadband-internet-subscriptions/, 2018, [Online; accessed11-April-2018].

[3] “4 billion people still don’t have internet access.” https://www.weforum.org/agenda/2016/05/4-billion-people-still-don-t-have-internet-access-here-s-how-to-connect-them/, 2018, [Online; accessed11-April-2018].

[4] R. C. Shah, S. Roy, S. Jain, and W. Brunette, “Data mules: modelinga three-tier architecture for sparse sensor networks,” in Proc. of IEEEInternational Workshop on Sensor Network Protocols and Applications.,May 2003.

[5] A. S. Pentland, R. Fletcher, and A. Hasson, “Daknet: Rethinking connec-tivity in developing nations,” Computer, vol. 37, no. 1, pp. 78–83, jan 2004.

[6] “KUHA Mobile Network,” https://www.kuha.io, 2018, [Online; accessed31-October-2018].

[7] “Telstra Media Release,” https://www.telstra.com.au/aboutus/media/media-releases/Telstra-trials-small-cell-technology-on-TasNetworks-infrastructure-to-fill-mobile-black-spots, 2018, [Online; accessed 28-March-2018].

[8] D. Tapscott and A. Tapscott, Blockchain revolution: how the technologybehind bitcoin is changing money, business, and the world. Penguin,2016.

[9] D. Fitchett, “Bank for agriculture and agricultural cooperatives (baac),thailand (case study),” Washington DC: Consultative Group to Assist thePoorest (CGAP) Working Group on Savings Mobilization, 1999.

[10] I. Mas and D. Radcliffe, “Mobile payments go viral: M-pesain kenya,” http://siteresources.worldbank.org/AFRICAEXT/Resources/258643-1271798012256/M-PESA_Kenya.pdf, 2010.

[11] T. J. MacDonald, D. W. Allen, and J. Potts, “Blockchains and the bound-aries of self-organized economies: predictions for the future of banking,”in Banking Beyond Banks and Money. Springer, 2016.

[12] A. Mackenzie, “The fintech revolution,” London Business School Review,vol. 26, no. 3, pp. 50–53, 2015.

[13] “Requirements and warnings - bitcoin core,” https://bitcoin.org/en/bitcoin-core/features/requirements, 2017, [Online; accessed 21-September-2017].

[14] “Ethereum’s Blockchain Size Surpasses Bitcoin’s by 40 Percent,”http://www.altcointoday.com/ethereums-blockchain-size-surpasses-bitcoins-by-40/, 2017, [Online; accessed 19-March-2018].

[15] M. Apostolaki, A. Zohar, and L. Vanbever, “Hijacking bitcoin: Routingattacks on cryptocurrencies,” in Security and Privacy (SP), 2017 IEEESymposium on. IEEE, 2017, pp. 375–392.

[16] K. Wüst and A. Gervais, “Ethereum eclipse attacks,” ETH Zurich, Tech.Rep., 2016.

[17] C. Natoli and V. Gramoli, “The balance attack against proof-of-work blockchains: The r3 testbed as an example,” arXiv preprintarXiv:1612.09426, 2016.

[18] Y. Marcus, E. Heilman, and S. Goldberg, “Low-resource eclipse attacks onethereum’s peer-to-peer network.”

[19] “Nokia Kuha: Community-run Small Cells,” http://smallcells.3g4g.co.uk/2017/06/nokia-kuha-community-run-small-cells.html, 2018, [Online; ac-cessed 28-March-2018].

[20] “Where Cellular Networks Don’t Exist, People Are Building Their Own,”https://www.wired.com/2015/01/diy-cellular-phone-networks-mexico/,2018, [Online; accessed 28-March-2018].

[21] R. L. Rivest and A. Shamir, “Payword and micromint: Two simple mi-cropayment schemes,” in International Workshop on Security Protocols.Springer, 1996, pp. 69–87.

VOLUME 4, 2016 13

http://ethdocs.org/en/latest/introduction/the-homestead-release.html

https://en.wikipedia.org/wiki/Global_Internet_usage

https://en.wikipedia.org/wiki/Global_Internet_usage

https://www.statista.com/statistics/268673/number-of-broadband-internet-subscriptions/

https://www.statista.com/statistics/268673/number-of-broadband-internet-subscriptions/

https://www.weforum.org/agenda/2016/05/4-billion-people-still-don-t-have-internet-access-here-s-how-to-connect-them/



https://www.kuha.io

https://www.telstra.com.au/aboutus/media/media-releases/Telstra-trials-small-cell-technology-on-TasNetworks-infrastructure-to-fill-mobile-black-spots



http://siteresources.worldbank.org/AFRICAEXT/Resources/258643-1271798012256/M-PESA_Kenya.pdf

http://siteresources.worldbank.org/AFRICAEXT/Resources/258643-1271798012256/M-PESA_Kenya.pdf

https://bitcoin.org/en/bitcoin-core/features/requirements

https://bitcoin.org/en/bitcoin-core/features/requirements

http://www.altcointoday.com/ethereums-blockchain-size-surpasses-bitcoins-by-40/

http://www.altcointoday.com/ethereums-blockchain-size-surpasses-bitcoins-by-40/

http://smallcells.3g4g.co.uk/2017/06/nokia-kuha-community-run-small-cells.html

http://smallcells.3g4g.co.uk/2017/06/nokia-kuha-community-run-small-cells.html

https://www.wired.com/2015/01/diy-cellular-phone-networks-mexico/



[22] R. Hauser, M. Steiner, and M. Waidner, Micro-payments based on iKP.IBM TJ Watson Research Center, 1996.

[23] G. Wood, “Ethereum: A secure decentralised generalised transactionledger,” Ethereum Project Yellow Paper, vol. 151, pp. 1–32, 2014.

[24] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W.Felten, “Sok: Research perspectives and challenges for bitcoin and cryp-tocurrencies,” in Security and Privacy (SP), 2015 IEEE Symposium on.IEEE, 2015, pp. 104–121.

[25] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.[26] C. Decker and R. Wattenhofer, “Information propagation in the bitcoin

network,” in IEEE P2P 2013 Proceedings. IEEE, 2013, pp. 1–10.[27] Y. Sompolinsky and A. Zohar, “Accelerating bitcoin’s transaction pro-

cessing. fast money grows on trees, not chains.” IACR Cryptology ePrintArchive, no. 881, 2013.

[28] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf,and S. Capkun, “On the security and performance of proof of workblockchains,” in Proceedings of the 2016 ACM SIGSAC Conference onComputer and Communications Security. ACM, 2016, pp. 3–16.

[29] M. Carlsten, H. Kalodner, S. M. Weinberg, and A. Narayanan, “On theinstability of bitcoin without the block reward,” in Proceedings of the 2016ACM SIGSAC Conference on Computer and Communications Security.ACM, 2016, pp. 154–167.

[30] K. Wüst and A. Gervais, “Do you need a blockchain?” IACR CryptologyePrint Archive, vol. 2017, p. 375, 2017.

[31] S. Kasahara and J. Kawahara, “Priority mechanism of bitcoin and its effecton transaction-confirmation process,” arXiv preprint arXiv:1604.00103,2016.

[32] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller,P. Saxena, E. Shi, E. G. Sirer et al., “On scaling decentralized blockchains,”in International Conference on Financial Cryptography and Data Security.Springer, 2016, pp. 106–125.

[33] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse attacks onbitcoin’s peer-to-peer network.” in USENIX Security Symposium, 2015,pp. 129–144.

[34] P. R. Rizun, “A transaction fee market exists without a block size limit,”Block Size Limit Debate Working Paper, 2015.

[35] T. Ojala, J. Orajärvi, K. Puhakka, I. Heikkinen, and J. Heikka, “panoulu:Triple helix driven municipal wireless network providing open and freeinternet access,” in Proceedings of the 5th International Conference onCommunities and Technologies. ACM, 2011, pp. 118–127.

[36] J. Poon and V. Buterin, “Plasma: Scalable autonomous smart contracts,”White paper, 2017.

[37] J. Poon and T. Dryja, “The bitcoin lightning network: Scalable off-chaininstant payments,” See https://lightning. network/lightning-network-paper.pdf, 2016.

[38] C. Blattman, R. Jensen, and R. Roman, “Assessing the need and potentialof community networking for developing countries: A case study from in-dia,” Harvard Center for International Development. edevelopment. media.mit. edu/SARI/papers/CommunityNetworking. pdf, 2002.

[39] P. Rimba, A. B. Tran, I. Weber, M. Staples, A. Ponomarev, and X. Xu,“Comparing blockchain and cloud services for business process execu-tion,” in Software Architecture (ICSA), 2017 IEEE International Confer-ence on. IEEE, 2017, pp. 257–260.

[40] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency with proof-of-stake,” self-published paper, August, vol. 19, 2012.

[41] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse, “Bitcoin-ng: Ascalable blockchain protocol.” in NSDI, 2016, pp. 45–59.

[42] D. Chatzopoulos, S. Gujar, B. Faltings, and P. Hui, “Localcoin: An ad-hoc payment scheme for areas with high connectivity,” arXiv preprintarXiv:1708.08086, 2017.

[43] T. Crain, V. Gramoli, M. Larrea, and M. Raynal,“(leader/randomization/signature)-free byzantine consensus forconsortium blockchains,” arXiv preprint arXiv:1702.03068, 2017.

[44] G. Karame, E. Androulaki, and S. Capkun, “Two bitcoins at the priceof one? double-spending attacks on fast payments in bitcoin.” IACRCryptology ePrint Archive, vol. 2012, no. 248, 2012.

14 VOLUME 4, 2016

A Delay-Tolerant Payment Scheme Based on the Ethereum...

Documents

Transcript of A Delay-Tolerant Payment Scheme Based on the Ethereum...