# A Mining Strategy for Minimizing Waiting Time in Blockchains for Time-Sensitive Applications

Authors: Gholamreza Ramezan; Cyril Leung; Chunyan Miao
Journal: Wireless Communications and Mobile Computing
 (2022)

---

## Abstract

Blockchain, as proposed in Bitcoin, focuses on securing financial transactions. However, in recent years, the use of blockchain has expanded to a wide range of networks and application domains. This includes time-sensitive applications which need transactions to be processed fast enough to meet delay requirements. Reducing the transaction waiting time in the mining process is key to the successful adoption of blockchain in such applications. In this paper, we propose a mining strategy that is aimed at minimizing the average waiting time per transaction by ensuring a certain minimum required block size, based on the average transaction arrival rate, mining service rate, and maximum block size. We derive an expression for the average transaction waiting time of the proposed mining strategy and determine the optimal mining rule. Numerical results show that the average waiting time per transaction can be reduced by up to15% using the proposed mining strategy compared to the traditional strategy in which miners immediately start the next mining round using the transactions already waiting in the pool.


---

## Body

## 1. Introduction

Blockchain technology, originally proposed in [1], is now widely used in different systems and applications. Cryptocurrencies, e.g., Bitcoin, focus on storing transactions of financial assets in the blockchain. However, it is also possible for other types of data to be stored and validated, including routing data [2] and spectrum access information [3].Blockchain systems (BCSs) employ a distributed ledger feature to offer trusted services without the need for a central authority (CA). As such, blockchain technology is being proposed for emerging communication networks. It can create a decentralized infrastructure and guarantee the immutability of the network control messages exchanged between network nodes. Moreover, blockchain improves the availability and reliability of the network by replacing a CA with a group of network nodes. Blockchain also supports smart contracts which can autonomously execute programs to follow the terms of agreements made between network nodes. It is expected that blockchain will play an important role in emerging networks such as beyond fifth-generation (B5G) [4], sixth-generation (6G) [5], or data centers [6]. Blockchain is also viewed as a promising technology for more efficient dynamic spectrum management. The U.S. Federal Communications Commission (FCC) has identified blockchain as a key technology to monetize dynamic spectrum sharing in 6G [7].There have been several studies on improving blockchain mining. In [8], the authors present a high-throughput, low-latency, deterministic confirmation mechanism called ACCEL for accelerating Bitcoin’s block confirmation mechanism. The key idea for achieving faster confirmation is the quick identification of singular blocks that provably belong to the blockchain. While it is impossible to determine with certainty if a block belongs to a blockchain when network delays are unbounded, singular block detection exploits the fact that the end-to-end latency between Bitcoin miners is substantially lower than the interblock spacing and can be assumed to be upper bounded. However, the proposed mechanism requires a permissioned blockchain. In [9], a sharding technique is proposed to boost throughput without compromising security and decentralization. Sharding partitions a large blockchain database into small chunks called shards. The blockchain network is sliced into multiple communities of a similar size, each individually processing a disjoint portion of data, e.g., a shard that contains transactions associated with members of a community. However, they require a change in blockchain database structure. In [10], the authors introduced a secure and low latency proof of work (SLPoW) protocol to bring the computation of miners onto a field-programmable gate array (FPGA) to improve the processing speed. In [11], the authors introduced a two-level hardware architecture for the SHA-256 hash algorithm processing. The first level helps the system reduce the number of operating cycles, and the second level increases the maximum system clock frequency. However, the protocols proposed in [10, 11] need dedicated hardware to improve the mining time. In [12], the authors introduce Blinkchain, a consensus protocol that relies on a sharding technique to provide a bound on consensus latency, proportional to the network delay between the blockchain buyer and seller nodes. Blinkchain selects a random pool of block miners, some of which are legitimate with high probability, to mine, even when a miner attacker focuses its mining power to crowd out legitimate miners in a small vicinity. However, it requires the existing blockchains to replace their consensus protocol with the proposed one. In [13], the authors propose two types of Bitcoin mining, namely, a cooperative (social optimum) mining strategy, and a noncooperative (selfish). It is shown that cooperation gives the miner a higher total profit compared to a situation when all miners act selfishly. In [14], the authors applied reinforcement learning (RL) to obtain the most profitable mining strategy. However, the proposed mechanism does not improve the mining time. In [15], the authors propose a framework to incentivize miners to mine honestly and help to increase the total welfare of blockchain networks. A mechanism to encourage cooperative mining is also proposed. In [16], the authors proposed a method for accelerating the process of proof of work (PoW) based on parallel mining rather than solo mining. The goal is to ensure that a group of miners does not put the same effort into solving a specific block. The proposed method includes a process for selecting a mining coordinator as well as distributing the mining work and mining reward.In contrast to the aforementioned works which study existing blockchain mining strategies, in this paper, we propose a new mining strategy. To use blockchain in communication networks, it should meet the delay requirements of network applications. Reducing the transaction waiting time in the blockchain mining process is key for blockchain to be used in time-sensitive applications. In a BCS, user transactions arrive at a transaction pool to await processing by miners. We refer to the time interval between the arrival of a transaction and the start of mining of a block in which it is contained as the transaction waiting timeW. Our proposed strategy is aimed at minimizing the average waiting time per transaction, W¯. If the number of transactions in the pool when a miner is ready to start a new mining round is relatively small, it may be advantageous for the miner to wait for some more transactions to arrive before starting the mining process. Thus, an interesting question is how many transactions the miner should wait for. In [17], we proposed a scheme in which miners wait for a certain minimum number, D, of transactions to be in the pool before starting a new mining round. However, the practical constraint of a finite number of transactions in a block was not considered. In this paper, we consider a finite block size B, i.e., B≥D is the maximum number of transactions in a block. We refer to the proposed mining strategy as Wait‐MinD,B, and note that the traditional no-wait strategy is simply Wait‐Min1,B. In Wait‐MinD,B, miners wait for a minimum of D transactions to arrive to the mining pool and B is the maximum number of transactions to be picked up from the pool. The main contributions of this paper are as follows:
(i)
We propose theWait‐MinD,B mining strategy and derive the average waiting time per transaction(ii)
We determine theoptimal value, D∗, which minimizes the average waiting time per transaction. It is found that for large values of B, D∗≈0.9λτ where λ is the average transaction arrival rate and τ is the average mining round service time(iii)
We validate our analysis through computer simulations. Results show that the average per transaction waiting time forWait‐MinD∗,B is about 15% lower than for Wait‐Min1,BThe remainder of this paper is organized as follows. A queueing model for a blockchain system and the proposedWait‐MinD,B strategy are described in Section 2. In Section 3, we derive the average transaction waiting time per transaction for the Wait‐MinD,B strategy. Numerical results are provided in Section 4. The main findings are summarized in Section 5.


## 2. System Model and ProposedWait‐MinD,B Scheme

### 2.1. System Model

We consider a blockchain system in a communication network that provides service to time-critical applications. The system consists of network nodes and miners, as shown in Figure1. Network nodes submit transactions to the transactions pool, and miners pick up transactions from the pool to generate (i.e., mine) new blocks. The newly generated blocks are appended to the blockchain and sent to network nodes upon request. Miners cooperate to generate new blocks.Figure 1
A blockchain-based communication network.We model the blockchain as a queueing system as shown in Figure2. User transactions arrive at the transaction pool queue according to a Poisson process with arrival rate λ and wait there until the miner (server) completes its current mining round. The miner then picks up transactions from the pool and starts generating the next block. We assume that the mining service time follows an exponential distribution with an average time of τ [18]. Note that miners provide service to a group of transactions in each mining round, i.e., the service time (i.e., mining time) in a mining round is independent of the number of transactions in the block. For the queueing system to be stable, we need λτ/B<1.Figure 2
Queueing model for a blockchain system.


### 2.2. Proposed Strategy

In a traditional mining strategy, after a miner completes a mining round, it will pick up all the transactions that are waiting in the pool queue and immediately start a new mining round.In the proposedWait‐MinD,B strategy, the miner waits until a minimum of D≥1 transactions are in the queue before it starts a new mining round. Although enforcing this time may increase the average transaction waiting time for the transactions already in the transaction pool, it may decrease the waiting times for the newly arrived transactions, resulting in a reduced overall average transaction waiting time.


## 2.1. System Model

We consider a blockchain system in a communication network that provides service to time-critical applications. The system consists of network nodes and miners, as shown in Figure1. Network nodes submit transactions to the transactions pool, and miners pick up transactions from the pool to generate (i.e., mine) new blocks. The newly generated blocks are appended to the blockchain and sent to network nodes upon request. Miners cooperate to generate new blocks.Figure 1
A blockchain-based communication network.We model the blockchain as a queueing system as shown in Figure2. User transactions arrive at the transaction pool queue according to a Poisson process with arrival rate λ and wait there until the miner (server) completes its current mining round. The miner then picks up transactions from the pool and starts generating the next block. We assume that the mining service time follows an exponential distribution with an average time of τ [18]. Note that miners provide service to a group of transactions in each mining round, i.e., the service time (i.e., mining time) in a mining round is independent of the number of transactions in the block. For the queueing system to be stable, we need λτ/B<1.Figure 2
Queueing model for a blockchain system.


## 2.2. Proposed Strategy

In a traditional mining strategy, after a miner completes a mining round, it will pick up all the transactions that are waiting in the pool queue and immediately start a new mining round.In the proposedWait‐MinD,B strategy, the miner waits until a minimum of D≥1 transactions are in the queue before it starts a new mining round. Although enforcing this time may increase the average transaction waiting time for the transactions already in the transaction pool, it may decrease the waiting times for the newly arrived transactions, resulting in a reduced overall average transaction waiting time.


## 3. Derivation of the Average Waiting Time

In this section, we derive analytic expressions for the average waiting time per transaction,W¯, for the Wait‐MinD,B strategy. Figure 3 shows the state transition diagram for the Wait‐MinD,B strategy. In state Ni, there are i=0,⋯,∞ transactions in the queue and the miner has not yet completed its current mining round. In state Wi, there are i=0,..,D−1 transactions in the queue and the miner which has already completed its current mining round is waiting for at least D transactions in the queue in order to start a new mining round. The transition from state Ni, i∈D,D+1,..,B, to state N0 indicates that when the miner completes its current round, it picks up all the transactions in the pool for its next mining round. The transition from state Ni, i>B, to state Ni−B indicates that when the miner completes its current round, and it can only pick up B transactions from the pool for its next mining round. A valid block in the Wait‐MinD,B mining strategy has a minimum of D and a maximum of B transactions.Figure 3
State transition diagram for theWait‐MinD,B strategy. In state Ni, i=0,1,⋯, there are i transactions in the queue and the miner has not yet completed its current mining round. In state Wi, i=0,1,⋯,D−1, there are i transactions in the queue and the miner has already completed its current mining round and will start a new mining round as soon as there are D transactions in the queue.LetπNi and πWi denote the stationary probabilities of states Ni and Wi, respectively. The probability, πi, of i transactions in the queue is given by
(1)πi=πNi+πWi,0≤i≤D−1,πNi,i≥D.We now derive expressions forπNi and πWi. Equating the flows in and out of state Ni yields
(2)λ+1τπNi=λπNi−1+1τπNi+B,i=1,2,3,⋯.Let the coefficientβ, 0<β<1, satisfy
(3)πNi=βiπN0.From (2), we can write
(4)λ+1τβiπN0=λβi−1πN0+1τβi+BπN0,i=1,2,3,⋯,i.e.,
(5)1τβB+1−λ+1τβ+λ=0.The value ofβ can be obtained from (5) and will be used later to calculate the average transaction waiting time W¯. Note that the value of β depends on B.Similarly, equating the flows in and out of stateWi, i=1,2,⋯,D−1, and using (3), we can write
(6)πWi=πWi−1+1λτπNi=πW0+1λτ∑j=1iπNj=πW0+1λτ∑j=1iβjπN0=πW0+1λτβ1−βi1−βπN0.Equating the flows in and out of stateW0 yields
(7)λπW0=1τπN0.Substituting (7) in (6), we have
(8)πWi=1λτπN0+1λτβ1−βi1−βπN0=1−βi+1λτ1−βπN0.Using the fact that
(9)∑i=0∞πNi+∑i=0D−1πWi=1,together with (3) and (8), we can obtain
(10)πN0=λ1−β21/τD1−β−β1−βD+λ1−β.LetL denote the transaction queue length. The average queue length, L¯, is given by
(11)L¯=∑i=0∞iπi.From (1), (3), and (8), πi can be obtained as
(12)πi=βiπN0+1λτ1−βi+11−βπN0,0≤i≤D−1,βiπN0,i≥D.Substituting (12) in (11) yields
(13)L¯=πN0∑i=0∞iβi+1λτ∑i=0D−1i1−βi+11−β.Using the fact that(14)∑i=0∞iβi=β1−β2,∑i=0D−1i1−βi+1=DD−12−β2−DβD+11−β−βD+21−β2,we can re-write (13) as
(15)L¯=πN0β1−β2+1λτ1−βDD−12−β2−DβD+11−β−βD+21−β2.Hereafter, we useL¯D,B instead of L¯ to explicitly show its dependence on D and B (through β). Using Little’s law [19], the average waiting time per transaction can be obtained as
(16)W¯D,B=L¯D,Bλ.For a given maximum block size value,B, we can readily find the optimal value, D∗, of D, D∈1,2,⋯,B, which minimizes W¯D,B.


## 4. Numerical Results

In this section, numerical results obtained using the expressions derived in Section3 are presented. Computer simulations were used to verify the analytical results. The simulation was performed using MATLAB version R2020b. Considering 210 bytes for a Bitcoin P2PKH (Pay to Public Key Hash) transaction [20], a blockchain with a maximum block size of 10 MB can include about B=50000 transactions. Assuming an average of λ=7 transactions per second [21] and an average block mining time τ, of 10 minutes, we have λτ=5000.Figure4 shows the average waiting time per transaction, W¯D,B, for λτ=5000 and B=50000. The optimal value of D which minimizes W¯D,B is D∗=4500. The average waiting time per transaction for Wait‐MinD∗,B is about 10% lower than that for the traditional Wait‐Min1,B strategy.Figure 4
Normalized average waiting time per transaction,W¯D,B/τ, for Wait‐MinD,B as a function of D with λτ=5000 and B=50000.Figure5 shows the probability, πi, of i transactions in the queue, obtained using (12) for λτ=5000, D=4500, and B=50000. Because miners do not pick any transaction from the queue as long as there are fewer than D transactions, the probabilities πi for i<D are the same. It can also be observed that πi drops sharply at i=D. This is not surprising since λτ>D and D is the minimum number of transactions needed before the miner starts a new mining round.Figure 5
Probability of havingi transactions in the queue in the Wait‐MinD,B strategy for λτ=5000, D=4500, and B=50000.Figure6 shows the normalized average waiting time, W¯D,B/τ, as a function of D/λτ for different values of λτ. The optimal value, D∗, of D is also shown. For any value of λτ, the optimal value of D is well approximated by D∗≈0.9λτ and W¯D∗,B is about 10% lower than that of the traditional Wait‐Min1,B strategy. Note that in the traditional mining strategy which is equivalent to Wait‐Min1,B, miners pick up transactions for mining purposes as long as there is at least 1 transaction in the pool.Figure 6
Normalized average waiting timeW¯D,B/τ as a function of D/λτ for different values of λτ, with B=50000. The optimal decision points, D∗, obtained from the analysis and simulation are also shown.Figure7 shows W¯D,B as a function of D for different values of B when λτ=5000. It can be observed that the average waiting time W¯D∗,B is lower by 10%, 12%, 15%, and 12% compared to the traditional Wait‐Min1,B strategy for B=50000, B=10000, B=7500, and B=6000, respectively. As the maximum block size B is reduced, D∗ increases with B, for B>7500. This is because the Wait‐MinD,B strategy tries to pack more transactions into a block to make more efficient use of the mining effort. Note that for B<7500, D∗ decreases with B since D cannot be larger than B.Figure 7
Normalized average waiting timeW¯D,B/τ as a function of D for different values of B, with λτ=5000.Figure8 shows the normalized optimal value D∗/λτ as a function of B/λτ obtained from analysis and simulation. It can be seen that for B/λτ<1.5, D∗=B. For B/λτ>1.5, D∗ decreases with B towards an asymptotic value of 0.9λτ. We also computed the results for λτ=50000. However, the results for λτ=50000 are not plotted in Figure 8 as the resulting curve is almost identical to the curve for λτ=5000. Figure 8 shows that there is close agreement between the analysis and simulation results of our analysis.Figure 8
Normalized valueD∗/λτ as a function of B/λτ with λτ=5000.Figure9 shows W¯D,B/τ as a function of D for different values of B/D when λτ=5000. As to be expected, for a fixed value of D, (e.g., D=5000), W¯D,B/τ decreases from 1.11 for B/D=2 to 0.9 for B/D=8. B/D=2 is lower by 12% compared to the traditional Wait‐Min1,B strategy. It can also be observed that the improvement decreases with B/D.Figure 9
Normalized average waiting timeW¯D,B/τ as a function of D for different values of B/D, with λτ=5000.


## 5. Conclusion

TheWait‐MinD,B mining strategy was proposed to minimize the average waiting time per transaction, W¯D,B, in a blockchain system. It shows that a minimum number of transactions should be included in each block. An analytic expression for W¯D,B was derived and verified using simulations. Numerical results show that the proposed strategy can reduce the average waiting time per transaction by as much as 15%, compared with the traditional strategy. It is also found that when the maximum block size is very large, a minimum of 0.9λτ transactions need to be included when generating a new block in order to minimize the average waiting time. A real implementation of the proposed strategy in Hyperledger is being considered.



---

*Source: 4352406-2022-03-09.xml*