A Delay-Tolerant Payment Scheme Based on the Ethereum Blockchain

Digital banking as an essential service can be hard to access in remote, rural regions where the network connectivity is unavailable or intermittent. The payment operators like Visa and Mastercard often face difficulties reaching these remote, rural areas. Although micro-banking has been made possible by short message service or unstructured supplementary service data messages in some places, their security flaws and session-based nature prevent them from wider adoption. Global-level cryptocurrencies enable low-cost, secure, and pervasive money transferring among distributed peers, but are still 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 unreliable networks in remote regions. We focus on a scenario where a community-run base station provides reliable local network connectivity while intermittently connects to the broader Internet. We take advantage of the distributed verification guarantees of the Blockchain technology for financial transaction verification and leverage smart contracts for secure service management. In the proposed system, payment operators deploy multiple proxy nodes that are intermittently connected to the remote communities where the local blockchain networks, such as Ethereum are composed of miners, vendors, and regular users. Through probabilistic modeling, we devise design parameters for the blockchain network to realize robust operation over the top of the unreliable network. Furthermore, we show that the transaction processing time will not be significantly impacted due to the network unreliability through extensive emulations on a private Ethereum network. Finally, we demonstrate the practical feasibility of the proposed system by developing Near Field Communication (NFC)-enabled payment gateways on Raspberry-Pis, a mobile wallet application and mining nodes on off-the-shelf computers.

SECTION I. Introduction

Internet access has evolved to be one of basic needs of 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 broadband Internet [2]. Nevertheless, there are still more than four billion people, mostly in developing regions, who do not have access to or can only intermittently connect to the broader Internet [3]. This has led to the development of distributed networking 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]. Another proposed solution for remote regions is Community-Run Base Stations (CBSs) for local-area connectivity, for example, Nokia Kuha base stations [6] and Telstra small cells [7] that enable connectivity to the broader Internet via Satellite connectivity. However, both these approaches do not guarantee the connectivity at all time.

In spite of these network irregularities, the ubiquitous availability of connectivity is taken for granted in the development and management of many services such as finance, entertainment, or health-care. As a result, customers of digital services and businesses in rural areas often face operational challenges associated with network connectivity, mainly due to the lack of robustness in digital service design and management. For example, none of the popular online payment schemes, including credit cards, will work well in these connectivity-restricted environments. Since all of these services rely on real-time verification and processing for security purposes. In fact, Tapscott and Tapscott [8] estimated that nearly two billion people worldwide still do not have access to basic banking services. Despite the paramount importance of online banking for economic growth, little has been done to deliver banking services to connectivity-restricted environments, due to the inability to meet the security requirements locally without connecting to the centrally controlled databases [9], [10].

Cryptocurrencies have received significant attention in recent years and are known for their ability to distributedly verify transactions [11], [12]. The technology behind, Blockchain, is achieved by hard-coded software programs and enables peer democracy to settle transactions. However, like most other pervasive services of today, cryptocurrencies also require continuous network connectivity to constantly exchange large volumes of data among the collaborators of the service. For instance, a typical Bitcoin client uses around 200 MB of data per hour [13] while the Ethereum blockchain size surpassed Bitcoin in June 2017 [14]. Moreover, partitioning of the network due to interruptions increases the chances of malicious activities and hinder the security guarantees of the blockchain [15]–​[18]. As a result, cryptocurrency-based solutions in its current form do not support to provide online banking services for connectivity restricted environments.

In this paper, we take advantage of distributed verification guarantees of Blockchain technology to design a novel digital payment system that can be deployed over the top of a network with a very low quality of service guarantees. Our focus is at remote rural villages with community-run base stations such as Nokia Kuha [6] that are connected to the public Internet via unreliable satellite links. We propose an Ethereum-blockchain-based local transaction verification scheme for online payment operators such as VISA and MasterCard and also leverage smart contracts for service management.

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 management such as user account initiation, interactions with credit operator and management of rewards for blockchain miners.

• Probabilistic modelling of the proposed system to devise robust design parameters for ensuring reliable functionality under regular as well as extreme operating conditions. Furthermore, we show that transaction processing is highly related to block creation, and with a sufficient block size, transaction arrival rate does not affect transaction processing time.

• Through extensive emulations on a private Ethereum platform, we show that network unreliability would not slow down transaction processing due to Proof-of-Work (PoW) difficulty adjustment and also the average block generation time is relatively stable even with unreliable availability of miners.

• Demonstrates practical viability of the proposed system through a prototype implementation of NFC (Near Field Communication) enabled payment gateways on Raspberry Pis and a mobile wallet on an off-the-shelf mobile devices.

The remainder of the paper is organized as follows: Section II provides background information on CBS, micro-payment systems. Section III describes the system architecture and Section IV presents models of the system design, followed by Section V that validates of our models and evaluates our solution over a local blockchain deployment. Section VI demonstrates a prototype implementation with multiple test results. Section VII discusses the related work. Section VIII highlights insights on future directions and finally Section IX concludes the paper. Additional key technical details of Ethereum blockchain are provided in Appendix.

SECTION II. Background

In this section, we introduce the concept of CBSs and existing solutions to deliver digital banking to remote regions.

A. Community-Run Base Stations (CBS)

Despite the advances in mobile technology, almost all countries still have disconnected rural areas where the mobile coverage is not available. Most mobile operators are reluctant to provide service to these areas due to various reasons such as limited roadway connectivity, high maintenance cost, lack of security for infrastructure, inability of secure return of investment.

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

B. Digital Banking in Remote Regions

To reduce the service cost and enable payments that involve very small sums of money, a number of micro-payment schemes were proposed. Some of them leverage SMS or USSD of the cellular networks, for instance, the Bank for Agriculture and Agricultural Co-operatives (BAAC) in Thailand [9] and the M-Pesa Service in Kenya [10]. However, SMS messages are easily spoofable and hence require additional user verifications for security, and USSD could be affected by session time-outs. Other micro-banking systems are the early-generation token payment platforms secured by time-lock puzzles, e.g. PayWord and MicroMint [21]. IBM also proposed a Micro-iKP protocol for frequent micro-payments [22] using “coupons” sent between players and verified by the bank. This scheme however, increases the communication cost.

SECTION III. System Architecture

The primary objective of the proposed architecture is to enable cheap, cashless payments for remote villages that have intermittent Internet connectivity. We consider the scenario where local network operators provide wireless coverages within remote communities, using technologies similar to Nokia Kuha [6]. The backhaul connection to/from outside of the communities is a low-bandwidth connection, e.g., a satellite link, that does not provide robust service guarantees.

We denote a set of payment operators as $O=\{o_{1},o_{2},o_{3}, {\dots }\}$ , of which each $o_{i}$ controls a set of proxy nodes, $P_{i}=\{p_{i1},p_{i2},p_{i3}, {\dots }\}$ . The proxy nodes each connects a corresponding village in $V_{i}=\{v_{i1},v_{i1},v_{i1}, {\dots }\}$ via the backhaul connection. As the village networks are relatively isolated, we propose to deploy blockchains for transaction processing in that they can be operated by individuals without any centralized authority. Our scenario also fits in the conditions of a public-permissioned blockchain according to the guidelines provided by Wust et al. [23]. For local blockchain deployment, we propose to use Ethereum [24] for its fast, decentralized consensus and verification guarantees. The village blockchains are independent from each other and operate on different Tokens.

As illustrated in FIGURE 1a, the proposed framework enables Regular Users or Customers to perform cashless financial transactions with Vendors in the village irrespective of the connectivity to the proxy. In addition, some villagers can participate in the decentralized verification and become Miners. Regular users can join the service by simply installing a mobile application on their personal devices, which operates a blockchain light node as shown in Figure 1b. Vendors and miners will be required to have additional hardware to run full nodes and mining nodes respectively. The proxies are full nodes themselves to avoid creating forks when rejoining the village blockchain. The proxy nodes continue to operate regardless of the condition of backhaul connection. There is no restriction on users joining the system. The account management and mining reward distribution are operated by proxies. Instead of the default Ether generation scheme, we propose to use a Token-based local currency to avoid inflation in the local economy.

FIGURE 1.

Overview of the proposed system. (a) System architecture. (b) Transaction flows.

The integration of Smart Contracts for admission control and the Token based service management is unique as it automatically imposes restrictions on users entering the system and makes it easier for the payment operators to manage user accounts, even when local blockchain network is disconnected from the proxy node.

A. Transaction Flow

FIGURE 1b illustrates transaction flows of the proposed framework. There are two types of transactions associated with regular users: i) regular transactions ($tx_{P,P}$ ) between regular users and vendors, and ii) currency exchange transactions ($tx_{B,P}$ ) for converting real money (fiat currency) to Tokens. To perform a regular transaction, every regular user first needs to load their digital wallet (associated with the mobile app) with Tokens. As shown in FIGURE 1b, once validated by a bank, the proxy issues a transaction $tx_{B,P}$ , which is picked up by Miner 1 and included in Block #i. Once $tx_{B,P}$ is confirmed, the code inside the Management Contract is triggered and Regular User 1’s Token account is updated accordingly as shown in Step ①. Next, Regular User 1 sends Vendor 1 a transaction $tx_{P,P}$ to obtain the service, which is collected by Miner 2 and confirmed in Block #i+1. Each regular transaction is treated equally, processed and authorized by the blockchain miners irrespective of the proxy node’s presence. During the proxy’s next synchronization, once it reaches Block #i+1, the smart contract is executed locally and the Token accounts of both Regular User 1 and Vendor 1 are updated as shown in Step ②. The proxy also creates two accounts for itself, just like other blockchain nodes.

If an outside party without Tokens wants to make transactions with people in the village, it first submits a request to the proxy. Upon validation, the proxy node converts the payment to the Token currency locally and redirects it to the target receiver. When Regular User A in Village A initiates a transaction with Vendor B in a Village B, Proxy A in Village A receives the request and notifies Proxy B in Village B, who settles the transaction in Village B and confirms with Proxy A. If Regular User A moves to Village B, she has to exchange new Tokens for spending in Village B as a unique Token is designated to each individual village.

B. Smart Contract Based Service Management

To avoid creating forks during disconnection, the payment operators deploy passive full nodes (Appendix A) as proxies. To track and manage the system operation, the payment operators create a smart contract, i.e. the Management Contract, to record account types, user balances in both fiat currency and Token currency, as well as distributing mining rewards. The proxy gets notified via the smart contract when a new user joins the system or when miners find blocks, and accesses the latest version of the ledger when it is connected. States in the smart contract are constantly updated regardless of the network condition between the village and the proxy. When connection is established, the proxy synchronizes with other blockchain nodes, updates user balances and processes currency exchange requests by issuing currency-exchange transactions ($tx_{B,P}$ in FIGURE 1b).

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

Algorithm 1

Management Contract

SECTION IV. System Modelling and Design

We first probabilistically model transaction processing of the local blockchain system and the synchronization delay of the proxy node. We also model the overall deployment and operational costs of one such system and use the models to design system properties to enable an efficient and reliable local area payments under the given network constraints.

A. Assumptions

We make the following assumptions without loss of generality:

1. All individual mining nodes have equal and stable computational power.

2. Block size is sufficient to include all transactions for immediate processing as the transaction rate within a village can be considerably lower compared to public Ethereum blockchain.

3. Zero transaction fees and no rewards for mining stale blocks as in the proposed system rewarding is controlled by the payment operator using Tokens.

4. Network bandwidth available within the village is sufficient for all blockchain related data traffic.

B. Modelling Transaction Processing

Regular transaction arrival $r_{t_{i}}$ , where $t_{i}$ is the transaction initiation time, follows a Poisson distribution as observed in [25]. We denote the average arrival rate as $\lambda _{t}$ transactions per second (tps). Block generation time $T$ has been shown to be exponentially distributed with probability density function $G(T)=\lambda e^{-\lambda T}$ , where $\lambda =\frac {1}{E[T]}$ [26]. In Ethereum, the expected block time $E[T]\approx 12s$ . Since we assume block size to be large enough (cf. assumption 2), there are no pending transactions as all new transactions arriving in the current mining session are included in the next block. Therefore, transaction processing time $t_{p} = T- t_{i}$ , where $t_{i}, t_{p} \in (0, T]$ . We further analyze the distribution of block time and transaction processing time under different arrival rates in Section V-B. Transaction throughput can also be calculated as $\frac {\sum _{\forall t_{i} \leq T} r_{t_{i}}}{T}$ . With transaction size being $s_{t}$ bits, a block needs to accommodate $s_{b}=s_{t}\sum _{\forall t_{i} \leq T} r_{t_{i}}$ bits of regular transactions, averaging $\bar {s_{b}}=\lambda _{t}s_{t}E[T]$ bits over multiple sessions.

There are currency-exchange transactions with the proxy full node when it is connected. We model currency-exchange transaction arrival $e_{t_{i}}$ similar to regular transactions with average arrival rate $\lambda _{e}$ and size $s_{e}$ . With these transactions, a block size is $s'_{b}=s_{t}\sum _{\forall t_{i} \leq T} r_{t_{i}}+s_{e}\sum _{\forall t_{i} \leq T} e_{t_{i}}$ , with the average being $\bar {s'_{b}}=(\lambda _{t}s_{t}+\lambda _{e}s_{e})E[T]$ .

C. Modelling the System Cost

We derive cost models from the payment operators’ point of view for mining rewards and system operation using the metrics in [27]. We omit transaction validation and storage costs in our calculations as they are only a small fraction of mining equipment cost and mining itself [27].

1) Rewarding Cost

Although the block reward is an incentive for miners, it is an extra cost for the payment operators. We use $R$ to denote the block reward, meaning that a payment operator has to spend $R$ Tokens for each valid block. We calculate the rewarding cost as $C_{R} = nR$ , where $n$ is number of blocks.

2) Network Resources

Since we assume ideal network conditions (cf. assumption 4) locally, we only model the network resource usage of the backhaul network. When connected, the proxy full node synchronizes past transactions and processes money exchange requests. We define one service period as $T_{S}=T_{C}+T_{U}$ , where $T_{C}$ and $T_{U}$ stand for the durations of connection and disconnection respectively.

We denote the backhaul network bandwidth requirement as $BW$ and cost as $C_{BW}$ in Token per bit. Then, the expected network connectivity cost would be $C_{N}=C_{BW}{T_{C}}{BW}$ during one service period.

3) System Cost

To sum up, the overall system cost to the payment operator is the sum of all the aforementioned costs. Since cost components are defined with different time units, we calculate the overall cost within time period $T_{0}$ , which equals $x_{b}$ blocks and $x_{s}$ service periods as:

$$\begin{equation*} C_{All} =C_{R}+C_{N}x_{s}=Rx_{b} + C_{BW}{T_{C}}{BW}x_{s}.\tag{1}\end{equation*}$$

D. Modelling the Proxy Node Synchronization

Regular transactions arrive when the proxies are connected via the back-haul link and when disconnected, while currency-exchange transactions only occur when the proxies are disconnected. We here assume the connection and disconnection periods to be much longer than block time. We use $n_{U}$ ($\sum _{i=1}^{n_{U}}T_{i}=T_{U}$ ) and $n_{C}$ ($\sum _{i=1}^{n_{C}}T_{i}=T_{C}$ ) to represent number of blocks created when connected and disconnected respectively. Transactions committed during one disconnected period can add up to a total size of $s_{U}$ . Substituting the block size derived in Part IV-B, we obtain,

$$\begin{align*} s_{U}=&\sum _{j=1}^{n_{U}}s_{b_{i}}=\sum _{j=1}^{n_{U}}s_{t}\left({\sum _{\forall t_{i} \leq T_{j}}r_{t_{i}}}\right) \\=&s_{t}\sum _{j=1}^{n_{U}}\sum _{\forall t_{i} \leq T_{j}}r_{t_{i}}=s_{t}\sum _{\forall t_{i} \leq T_{U}}r_{t_{i}}\approx {\lambda _{t}}{s_{t}}{T_{U}}\tag{2}\end{align*}$$

We do not consider network delay or communication overhead when the proxy node establishes connections with the village network. We use $t$ as the time passed since the beginning of the connection and denote data remaining to be synchronized as $s_{r}$ ,

$$\begin{align*} s_{r}=&s_{U}+\left({{s_{t}}\sum _{\forall t_{i} \leq t}r_{t_{i}}+{s_{e}}\sum _{\forall t_{i} \leq t}e_{t_{i}}}\right)-{BW}t \\\approx&s_{U}+(\lambda _{t}s_{t}+\lambda _{e}s_{e})t-{BW}t\tag{3}\end{align*}$$

When new transactions arrive, synchronization only finishes when the connection closes. When ${BW}$ is big enough, there exists a time $t_{0}$ ($t_{0}\leq T_{C}$ ), from which data remaining to be synchronized reaches 0, i.e., $s_{r}=s_{U}+(\lambda _{t}s_{t}+\lambda _{e}s_{e})t_{0}-{BW}t_{0}=0$ . Hence,

$$\begin{equation*} t_{0}=\frac {s_{U}}{BW-(\lambda _{t} s_{t}+\lambda _{e} s_{e})}.\tag{4}\end{equation*}$$ To find the range of ${BW}$ that satisfies Equation 4, we let $t_{0}\leq T_{C}$ , i.e., $\frac {s_{U}}{BW-(\lambda _{t} s_{t}+\lambda _{e} s_{e})} \leq T_{C}$ , from which we obtain $$\begin{equation*} BW \geq (\lambda _{t} s_{t}+\lambda _{e} s_{e})+{s_{U}}/{T_{C}}.\tag{5}\end{equation*}$$ When $BW$ is small, i.e., $BW < (\lambda _{t} s_{t}+\lambda _{e} s_{e})+s_{U}/{T_{C}}$ , there will always be data left when connection closes. Over time new transactions accumulate and the proxy node cannot access the latest version of the ledger.

E. Mining Network Design

We now find ranges of multiple mining network parameters including number of miners and their connectivity to ensure reliability and security.

1) Miner Outages

Miners are incentivized to work, but they may join or leave the network spontaneously (churn) [28]. We denote the total number of online miners as $l_{on}$ , $l_{on}\leq l_{m}$ . The probability of one miner going offline in each time slot is $p_{1}, p_{2}, p_{3}, \cdots, p_{l_{m}}$ . Hence the probability that $X=k$ miners are offline in the same time slot can be represented by a Poisson Binomial Distribution:

$$\begin{equation*} P_{r}(X=k)=\sum _{A\in F_{k}} \prod _{i\in A}p_{i} \prod _{j\in A^{c}}(1-p_{j}),\tag{6}\end{equation*}$$ where the set $F_{k}$ contains all subsets of k integers that can be selected from $\left \{{1,2,3,\cdots,l_{m}}\right \}$ , and $A$ and $A^{c}$ are complementary. If all miners have the same chance of going offline, i.e. $p_{1}=p_{2}=p_{3}=\cdots =p_{l_{m}}=p_{d}$ , the expectation of $l_{on}$ is: $$\begin{equation*} E[l_{on}]=l_{m}-E[X]=l_{m} (1-p_{d}),\tag{7}\end{equation*}$$ or equivalently, $$\begin{equation*} l_{m} = \frac {E[X]}{p_{d}} = \frac {E[l_{on}]}{1-p_{d}}.\tag{8}\end{equation*}$$ We demonstrate how network churn affects the blockchain system performance in Section V-C.

2) Mining Reward

Payment operators determine the mining reward $R$ according to the status of local economy and its budget. It becomes harder for each individual miner to find a valid block when there are more competitors (cf. assumption 1). As the expected reward reduces, mining becomes less profitable. We calculate the minimum mining reward needed to keep miners incentivized. We denote the mining cost as $\eta$ per hash, similar to [29]. With individual hash rate being $h$ , each miner’s operational cost per second is $\eta h$ . The expected hash cost of the entire network per second $C_{H}$ when all miner are online (worst case) is $C_{H}=l_{m}\eta h$ . Since miners are equal, their expected revenue per mining round is $R'=R/l_{m}$ . We do not consider rewards provided for stale blocks (cf. assumption 3). We derive the expected profit per mined block for each individual as:

$$\begin{equation*} \Pi =R'-\frac {C_{H} T}{l_{m}}=\frac {R}{l_{m}}-\eta hT.\tag{9}\end{equation*}$$ Clearly, for mining to be profitable, $\Pi$ should be greater than 0, i.e., $R$ should satisfy: $$\begin{equation*} R>l_{m}\eta hT.\tag{10}\end{equation*}$$

3) Minimal Connectivity Requirement

A key factor of blockchains is the synchronization across the network, i.e. every node should obtain a copy of the ledger. Individual miners may want to reduce their data usage by connecting to fewer other nodes, but for security all miners are encouraged to connect to as many other peers as possible. We here provide an intuitive picture on the minimal direct connections required for efficient information propagation across the network. For simplicity, we assume that on average every miner maintains connections with $l_{c}$ other nodes, $0 < l_{c}\leq l_{m}$ . Once Miner A receives a transaction or a block, she sends it to all her directly connected nodes. The same procedure repeats until the message reaches every node in the network. We define information propagation from one network node to another as a hop. Restricting maximum number of hops to $k$ , we obtain:

$$\begin{align*}&\hspace {-2pc}1+l_{c}+l_{c}(l_{c}-1)+\cdots +l_{c}(l_{c}-1)^{k-1} \\=&1+l_{c}\sum _{i=0}^{k-1}(l_{c}-1)^{i} \geq l_{m}.\tag{11}\end{align*}$$ We solve Equation 11 under given $k$ and $l_{m}$ . We do not use $l_{on}$ as eventually all miners will store the blockchain. We obtain $\gamma$ , fraction of nodes that one should directly connect to as: $$\begin{equation*} \gamma \geq \frac {min\left ({l_{c}}\right)}{l_{m}}.\tag{12}\end{equation*}$$

F. Summary

Although the payment operators’ intention is to have fewer mining nodes to reduce the equipment cost, there should be sufficient miners to keep the fairness of the system. The payment operators should also consider real-world churn rate and network resource costs to determine the mining reward. Furthermore, all villagers, especially miners, are recommended to increase their connectivity for better synchronization even though this leads to higher bandwidth usage.

SECTION V. Evaluation

In this section, we first validate our transaction processing model by comparing it to a real deployment of a private Ethereum blockchain and make predictions about the system behavior based on the validated model. We also dimension the local blockchain network design to satisfy the minimum average connection required for each mining node. Finally, we evaluate the blockchain performance under different network conditions on the experimental deployment.

A. Experimental Environment

We deployed a private Ethereum blockchain on multiple virtual machines running Ubuntu Linux v16.04 in an Openstack environment.¹ Each virtual machine is given 1 virtual CPU core, 2 GB of memory, and 10 GB of persistent storage to meet the minimum hardware requirement for running Ethereum. Elastic Search² was used to store block-related information. The network behavior was monitored using the Python Web3 Library.³

All virtual machines are linked together in a low-latency local network that can be customized on demand. Nodes are connected via a single Gigabit Ethernet switch and form a star topology similar to the cellular network shown in FIGURE 1a. With this setup, a communication round-trip time between any two nodes is less than 1 ms on average. We employ Linux traffic control to introduce delays to emulate the high latencies in mobile networks and configure the Linux kernel firewall with Iptables⁴ to emulate churns.

We used Geth v1.6.4 ⁵ for all of our empirical evaluations. Before the actual experimentation, we let the system stabilize for a few hours to obtain appropriate parameters of the genesis block in later runs. Based on our observations, we set the initial nonce value, gas limit and difficulty to $0\times 42$ , $0\times 08000000$ , $0\times 400000$ respectively to make the system stabilize quickly. To form a fully connected P2P blockchain network, we disabled the auto-discovery feature supported by Geth and configured the overlay network manually. Finally, if not mentioned otherwise, all experiments involved 10 mining nodes and 10 light nodes.

B. Model Validation and Numerical Sensitivity Analysis

1) Model Validation

To validate our model described in Section IV-B, we emulated a transaction processing scenario by issuing transactions at 1 tps (overall rate) from multiple clients to randomly selected addresses. We sort block timestamps in ascending order and calculate block generation time as the difference between two adjacent timestamps. To obtain transaction processing time, we record the timestamp upon initiation of a transaction and extract the inclusion timestamp from the transaction receipt. FIGURE 2a and FIGURE 2b present the simulation and emulation results of 500 consecutive blocks. Both illustrate a strong agreement between modelling and experimental measurements. Additionally, an inter-comparison between FIGURE 2a and FIGURE 2b confirms that transaction processing and block generation are highly correlated.

FIGURE 2.

Block generation and transaction processing. (a) Block time. (b) Transaction processing time.

2) Impact of Transaction Arrival Rate

We then intended to empirically study the impact of transaction rate on transaction processing and benchmark the local blockchain performance. However, when increasing the arrival rate, we hit the transaction sending limit before the processing limit due to implementation flaws in the Ethereum version we used. Indeed, with more than 3 tps, the transaction generator stopped working due to connection errors as the algorithm assumes that some nodes are flooding the system with too many requests. Despite that the transaction generator worked smoothly with lower arrival rates, in the end only 4246 out of 17265 transactions were mined at 2 tps. We hence decided to analytically study the system behavior under multiple transaction rates.

Using the validated model in Part V-B.1, we further generated transactions at various rates including 0.2 tps, 1 tps, 5 tps, and 25 tps in our simulation. FIGURE 3a and FIGURE 3b compare the 50th, 70th, 90th, 95th and 99th percentiles of block time and transaction processing time under all the simulated arrival rates. These results confirm that with a sufficiently large block size, block creation time and transaction processing time are not affected by the arrival rate.

FIGURE 3.

Simulation with multiple transaction rates. (a) Block time. (b) Transaction processing time.

3) Proxy Node Synchronization

We simulated 50 consecutive services sessions with the disconnection and connection in each service session being ${T_{U}}=9$ hrs and ${T_{C}}=1$ hr respectively. We estimated the transaction size to be 200 bytes from the real-life data collected by https://www.blockchain.comBlockchain.Info, and an average rate of 2 tps and 1 tps for regular and currency-exchange transactions respectively. Figure 4a illustrates data remaining to be synchronized by the proxy node over these 50 consecutive service sessions. We use bandwidths of 4 Kbps and 128 Kbps to show the two scenarios discussed in Part IV-D. Indeed, under a large synchronization bandwidth, the proxy node can always access all transactions by the end of a service session. When the bandwidth reduces, new transactions accumulate, making it impossible for the proxy to catch up.

FIGURE 4.

Simulated synchronization results. (a) Data remaining. (b) Synchronization delay.

We then analyzed the synchronization when transactions only arrive during disconnection. We did not limit the connection duration and measure the time taken for a full synchronization averaged over 10 service sessions, with ${T_{U}}$ ranging from 1 min to 10 min and $T_{C}$ unlimited. A distribution of the synchronization times is shown in Figure 4b. The result with off-the-shelf devices is presented in Part VI-B.1.

4) Minimal Connection Requirement

Based on the analysis presented in Part IV-E.3, we obtain the minimal connection requirement when varying number of hops $k$ from 1 to 4 in (Condition 11) with a total number of miners $l_{m}$ increasing from 4 to 100. FIGURE 5 displays the results in the number of nodes and fraction of the network. Minimum $l_{c}$ that satisfies Condition 11 may remain unchanged for a range of $l_{m}$ , which results in steps or spikes on the curves. As shown in FIGURE 5a, when $k=2$ , with a total of 100 miners, each individual needs to maintain at least 10 connections. When $k=3$ , the minimum number of connections required reduces to 4. Generally, if only one hop is allowed for information propagation, all miners need to connect with all other miners. While if more hops are allowed, miners can reduce the number of their connections and save the bandwidth usage. This indicates the system’s ability to scale without miners exhausting their network resources.

FIGURE 5.

Minimal connection requirement. (a) # of connections. (b) Fraction of the network.

C. Effect of Network Disturbances

To further evaluate the performance of the local blockchain network, we investigated its behavior under disturbances such as Network Delays and Network Churns. Since it was impossible to obtain the whole picture from transaction processing (cf. Part V-B.2), we have considered block generation time to be an alternative evaluation metric (cf. Part V-B.1).

1) The (Non) Impact of Network Delays

In order to understand the stability of the proposed system when inter-node delay increases, we introduced various delays of 0, 10ms, 50ms, 100ms, 500ms, and 1000ms per connectivity channel.⁶ FIGURE 6a shows the 50th, 70th, 90th, 95th, 99th percentiles of block time, from which it is possible to observe that the block time remains stable even with delays reaching 1 second. We ascribe this to PoW difficulty adjustment where network delay causes time difference between two adjacent blocks to increase, and as a result the internal algorithm reduces difficulty level to achieve a shorter block time. FIGURE 6b illustrates block difficulty under multiple network delays. A decreasing trend can be observed in the difficulty level when delay increases. This behavior helps to maintain the transaction processing speed, but is undesirable because with a fixed total network hash rate, a lower difficulty level leads to more stale blocks and inconsistencies.

FIGURE 6.

System behavior with network delays. (a) Block time percentiles. (b) PoW difficulty levels.

2) Network Churns

a: Transient Response

One of the main concerns of P2P networks is the churn rate of nodes. We emulated a scenario in which some miners go offline at time $t_{0}$ and observed variation in block creation time. 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 adjusted in response to changes in network hash rate. To find the end point of the “resolving period”, we select the timestamp from which the absolute variation is less than 5% for the next 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. While the network recovers, we also observed “backwards mining”, where newer blocks sometimes have smaller block number than older ones. The disagreement is resolved with the stabilization of the network.

FIGURE 7.

Transient response to mining nodes going offline.

b: Changes Over Time

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

FIGURE 8.

System steady-state behavior with network churns.

3) Summary

Despite being unable to test the processing limitation due to the shot comings of the Ethereum implementation and obtaining all transactional data experimentally, we managed to study the effect of network disturbances. Difference between empty blocks and blocks with transactions depends on block size, hence the additional transmission delays which are expected to have similar impacts to network delays. Results show that delays and churns may cause block generation time to change especially in the transient state. However, due to the difficulty adjustment they do not necessarily slow down block generation in the long run. Overall, the main observed drawback of the local blockchain is that disturbances may cause more temporary inconsistencies.

SECTION VI. Implementation

We demonstrate the feasibility of the system a prototype implementation containing a private Ethereum blockchain and an intermittently connected proxy node was implemented. We tested the synchronization delay of the proxy node when varying the bandwidth and disconnection duration. We also measured the usage of data, CPU, and battery of the mobile wallet app using DDMS ⁷ and Battery Historian.⁸

A. Setup

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

TABLE 1 Devices and Their Capabilities

FIGURE 9.

Prototype implementation.

We used a D-Link DSR-250N Wi-Fi router connected to the Oulu public WAN (PanOULU) [30] to emulate the community base station. We used an IEEE 802.11n Wi-Fi network to emulate the local network and interconnect the above. The proxy node’s backhaul bandwidth via the router’s WAN port. The auto-discovery protocol of Geth was used on all nodes.

We installed an application developed in Python 2.7.12 on the proxy node to update the account information. It is implemented on a Raspberry Pi 3, which also acts as an Ethereum full node. This application synchronizes with the blockchain using the Python-JSON RPC library.⁹ It keeps track of the connectivity and update the account balances in SQLite database. We have also developed a smart contract in Solidity v0.4.12 for token creation, conversion and transfer (cf. Section III).

Each payment gateway is composed of one Adafruit PN532 NFC module and a Raspberry Pi 3 attached to a touchscreen, as shown in Figure 10. After entering the amount, the vendor can select from multiple payment options. The application also synchronizes with the blockchain for confirmation of token transfer. Once the payment has been confirmed in the user wallet and a block is created, a new transaction is recorded on the blockchain. At the same time the transaction receives one block confirmation and the payment gateway notifies 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 joins the blockchain as a light node, which submits and retrieves transactions directly to/from the blockchain. Both NFC and QR code based payment modes are embedded in the app. After the user selects a payment method, the app asks the user to confirm the transaction information. Once confirmed, the app signs the transaction and submits it to the Ethereum blockchain. The app also shows the account balance, recent transaction history and can store multiple Ethereum accounts.

FIGURE 11.

Mobile wallet application.

B. Measurements

1) Proxy Node Synchronization

We emulated a situation where transactions are only committed during disconnection, as described in Part V-B.3. FIGURE 12a illustrates the average synchronization delay and variation over 10 runs of each scenario. Compared to the simulation results in Figure 4, the synchronization time does not increase proportionally with the disconnection duration, especially for bandwidths higher than 512 Kbps. This is because TCP communication speed cannot reach the maximum bandwidth at the beginning of the connection. When disconnection lasts for only a few minutes, data to be downloaded by the proxy node is small and synchronization finishes before TCP communication reaches its maximum bandwidth. As the disconnection duration increases, the amount of data to be downloaded also increases, TCP communication can reach a higher and more stable bandwidth during the synchronization, which results in the decrease in the slope of the plots.

FIGURE 12.

Test results on prototype implementation. (a) Synchronization delay. (b) Mobile wallet data usage.

2) Mobile Wallet Performance

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

SECTION VII. Related Work

We categorize related work into i) Side-Chain and Off-Chain Solutions, ii) Pervasive, Delay-Tolerant Networks, and iii) Blockchain Cost Models.

A. Side-Chain and Off-Chain Solutions

A number of side-chain and off-chain solutions have been developed to solve the on-chain scalability problem. The main idea is to shift part of the transactions away from the main chain. As side-chain and off-chain solutions can work independently from the main chain, they have the potential to be applied to intermittently connected environments. However, although there are implementations like Ethereum Plasma [31] and Bitcoin Lightning Network [32], the available platforms are still at their early stage and are yet to be deployed widely. For example, side-chains like Plasma increase complexity when it comes to data availability and block withholding attacks. While off-chain solutions like Bitcoin Lightning lacks flexibility during channel opening and closing. In addition, as an off-chain channel only involves two parties, in comparison to a public blockchain, complete trust is hard to achieve between only the two.

B. Pervasive, Delay-Tolerant Networks in Remote Regions

Delay-tolerant networks can be a potential solution to deliver Internet services to developing regions. Blattman et al. [33] found delay-tolerant networks are sufficient for digital services to meet the needs of most rural communities. Pentland et al. [5] later developed DakNet that uses a pervasive mobile coverage to enable asynchronous digital services in India and northern Cambodia. DakNet is remarkably low-cost and well-received by local users as it is more accessible than a centralized, community telephone. The success of DakNet proves that decentralization is an effective way to deliver service to remote regions.

Taking use of a CBS, together with an intermittent connection 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 from outside. However, delays can greatly affect the security of blockchains whose operation relies on continuous network connectivity when forks happen. To avoid forming disagreements during the disconnection, we only operate a full node as the proxy.

C. Blockchain Cost Models

Croman et al. [27] did a reality check of Bitcoin and analyzed the cost to confirm transactions. Rimba et al. [34] later proposed cost models using parameters such as gas and gasPrice to compare Ethereum with cloud services for business process execution. We stick to findings in [27] to obtain deployment and operation costs as the gas-related parameters can be adjusted by the bank.

SECTION VIII. Discussion

Although the ultimate control belongs to the payment operator, the reliable operation of the system is achieved via decentralization. Compared to traditional, centralized solutions, our approach is robust against node churn and can effectively avoid single-point-of-failure with lower deployment cost. However, some aspects of the system design can be further improved.

A. Blockchain Inefficiency

PoW is a heavy consensus algorithm, and its inefficiency becomes more significant in public cryptocurrencies. It was not problem in our prototype implementation. As blockchain technology evolves, lightweight consensus protocols are being explored [35]–​[38]. If it was to become a problem, these new protocols can be easily incorporated with the proposed system.

B. Security

In this paper, we have demonstrated the case where there are no intended, malicious behaviors. Below we present a brief discussion on security based on the current literature.

1) Temporary Inconsistency (Not a Real Threat)

Even though blockchain forks or stale blocks are an important indicator of inconsistency [26], if players behaves honestly, all conflicts can be resolved eventually. Hence, stale blocks themselves are not a direct threat to network security. However, they increase the chance of double-spend attacks that are usually caused by disagreements within the network [39].

Countermeasure: As suggested by Karame et al. [40], double-spend attacks can be mitigated by applying a “listening period” of a few seconds on the recipient side. In the proposed system, this can be integrated into the mobile wallet design.

2) Network Partitioning (A Real Threat)

An attacker who knows about other nodes and their connections can perform routing attacks to partition the network, such as the eclipse attack performed by [16], and the balance attack [17].

Countermeasure: Two potential countermeasures can be deployed, one centered around the proxy and another around participating node themselves.

In the first case, we can enable the proxy to deploy a smart contract that tracks node connections and detects network partitioning. When the proxy is connected, it accesses results generated by this smart contract. If subgraphs are detected, the proxy can take action, e.g. to force nodes in the subgraph to restart and refresh their connections as suggested by Apostolaki et al. [15]. Furthermore, full nodes and light nodes can also help to increase connectivity, and mitigate network attacks. In the second one, participating nodes themselves keep track of their own connections and changes in the network topology. As for a network partitioning attack to succeed, significant changes in the observable topology are needed [17], if a node observes that it lost a large number of its peers within a small timeframe, transactions can be frozen until the overlay network stabilizes again.

C. The Delayed Actions

Limited by the intermittent connectivity, in the current system, a user can only exchange tokens with the proxy when a connection is available. In addition, although network data is collected and analyzed in real time by miners, proxy control does not happen immediately.

SECTION IX. Conclusion

We proposed a blockchain-based payment scheme for intermittently connected regions. As a result, we have achieved this through a novel use of smart contracts and a token-based admission control, account management, and mining rewards distribution. Through mathematical models we analyzed system dynamics and the costs for the setup and operation. We then validated the proposed system through prototype implementation on a private Ethereum testbed and demonstrated the practicality of system design using off-the-shelf laptops and mobile devices. Finally, through a comprehensive study of the local blockchain operation, we showed the system stability under network disturbances and demonstrated the whole system operates well in resource-constrained, dynamic, intermittently connected environments.

In the future, we will address security vulnerabilities further and look into solutions that enable seamless operation under network irregularities. In addition, we will explore the potential of using the proposed management framework in other domains.

Appendix Ethereum Basics

We base our system design on the Ethereum platform [24], as it has a short block-generation time that makes it easy to generate large volume of block data for analysis. A summary of key terminology that is required to understand the Ethereum mechanisms is presented below.

SECTION A. Nodes and Their Connectivity

A blockchain consists of a P2P communication overlay network. In the case of Ethereum, each network node continuously attempts to connect to other nodes until they have peers. By default, Ethereum nodes use a gossip protocol to find out about other nodes. Each node maintains connections to a few peers either discovered during startup through the P2P protocol, or manually added using their public IP addresses.

Once the overlay network is created, nodes on a blockchain may act as full nodes, miners or light nodes. All nodes contribute to the network connectivity and information (i.e., transactions and blocks) propagation. Miners and full nodes verify all transactions based on their signatures and update any state changes, and keeps a complete transaction record. In addition, miners settle transactions via a process called mining as explained in Part IX-C. Light nodes operate in the Simplified Payment Verification (SPV) mode and only download block headers and verify and store transactions that are related to them. Table 2 summarizes node types and their capabilities in a typical blockchain network.

TABLE 2 Summary of Node Capabilities

SECTION B. Transaction, Block and Smart Contract

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

Ethereum also uses smart contracts to automatically form agreements among different entities. Smart contracts are identified by contract accounts, which are similar to EOAs but are associated with “code” that can be triggered by transactions or messages (calls) received from other EOAs or contracts. Smart contracts also have storage capabilities. The states recorded in a smart contract are updated upon a valid transaction and the messages it carries.

Transactions can be sent between two EOAs, two contract accounts, or an EOA and a contract account. In the public Ethereum network, miners may also collect transaction fees to make a profit [24]. Transaction priority, i.e. how likely and how soon a transaction is to be picked up by miners, depends mostly on its value, age and the transaction fee attached. State of a blockchain is computed after every block [41], and the code in smart contracts is executed by all nodes when synchronization happens (cf. Part IX-C).

SECTION C. The Blockchain

Nakamoto in his original paper proposed a PoW scheme to confirm transactions and select representation in majority decision making [42]. PoW is also adopted by the current version of Ethereum as described below.

1) PoW Mining and Difficulty Control

PoW mining is essentially the process of repeatedly calculating a hash value with an incrementing nonce until the hash is smaller than a target. Hashrate is the speed at which a miner computes hashes. Miners compete against each other in solving PoW puzzles and broadcast blocks to the rest of the network upon block creation for validation and synchronization. In addition to mining, miners also listen for new transactions and blocks discovered by others to prepare the next block.

Difficulty is a measure of how difficult it is to solve a PoW puzzle. Difficulty adjustment over PoW puzzles leads to a stable block creation rate. In Ethereum the calculation is based on the block number, timestamp of the current block, and timestamp & difficulty of its parent block. For Ethereum Homestead,¹⁰ the adjustment is always a multiple of parent_diff // 2048, with parameter $a \in \left [{-99, 1}\right]$ . We denote block_timestamp – parent_timestamp as $\delta t$ , and summarize the adjustments in Table 3. Difficulty adjustment is insignificant under a high network hashrate.

TABLE 3 PoW Difficulty Adjustments

2) Consensus and Chain Growth

Transmission delays may lead to stale blocks, or forks [26] as multiple blocks could be created at the same time, and received by different nodes across the network. A block is attached to the chain once created, with its own block header pointing to the previous block header, and all the way back to the genesis block. All peers work out these inconsistencies by selecting the longest chain. Ethereum determines the longest chain based on the total difficulty of all the blocks.¹¹

3) Node Synchronization

Network delays and node churns are common in blockchain systems. If one node restarts after going off-chain, it enquires its peers to obtain the latest version of the ledger. States stored in a particular block can only be accessed if the node synchronization has reached it.

SECTION D. Coin Supply

To compensate the resources consumed in mining, a fixed amount of new tokens, or mining reward, is generated upon the creation of blocks and paid to the winners. This rewarding scheme is necessary as it makes the blockchain more secure [44], but the continuous creation of coins may result in inflation.