A Real-Time Chain and Variable Bulk Arrival and Variable Bulk Service (VBAVBS) Model with λ_F

Abstract

This paper proposes a real-time chain and a novel embedded Markovian queueing model with variable bulk arrival (VBA) and variable bulk service (VBS) in order to establish and assure a theoretical foundation to design a blockchain-based real-time system with particular interest in Ethereum. Based on the proposed model, various performances are simulated in a numerical manner in order to validate the efficacy of the model by checking good agreements with the results against intuitive and typical expectations as a baseline. A demo of the proposed real-time chain is developed in this work by modifying the open source of Ethereum Geth 1.9.11. The work in this paper will provide both a theoretical foundation to design and optimize the performances of the proposed real-time chain, and ultimately address and resolve the performance bottleneck due to the conventional block-synchrony by employing an asynchrony by the real-time deadline to some extent.

1. Introduction

Blockchain technology [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20] is a new internet protocol to address the longtime-awaited solution for internet trust. Blockchain is a distributed ledger [4,5,7] of all the transactions that have been executed. Blockchains are distributed databases that a group of individuals controls and that store and share information. There are many different types of blockchains: Public, permissioned, private. Irrespective of the type of the blockchain, cryptography is used to allow each participant on any given network to manage the ledger in a secure way without the need for a central authority to enforce the results. The blocks are appended successfully to the blockchain, and more importantly, a block once appended cannot be removed from the blockchain. This makes the blockchain able to create trust in digital data. Blockchains basically eliminate the need for a third-party intermediary. When data is permanent and reliable in a digital format, one can transact business online in ways that, in the past, were only possible offline or would take a lot of time to process online.

The motivation and objective of this paper is to develop a real-time chain model in a theoretical manner, and to propose a novel embedded Markovian queueing model [19] of the $M^{1,n}/M^{1,n}/1$ type in order to establish a theoretical foundation to design a blockchain-based real-time system with particular interest in Ethereum, since there has been no adequate model to fulfill the above-mentioned objectives. The model assumes variable bulk arrivals of transactions in Poisson distribution, i.e., $M^{1,n}$, where $n$ is the number of slots across all the mined transactions, and variable bulk service of transactions in exponential time, i.e., $M^{1,n}$, for posting in the current block, namely, variable bulk arrival and variable bulk service (VBAVBS) model with ${\lambda }_F$, where ${\lambda }_F$ is a random variable employed specifically to address the stringent real-time deadline requirement. The primary performance measurements of interest are the average number of slots no matter how many transactions are mined under the assumption of maximum number of slots per block as specified by $n$; the average waiting time per slot; and the throughput in terms of the average number of slots to be processed per time. The variable bulk arrival rate is assumed to be linearly proportional to the size of the transactions in a multiple of λ per slot, with success to arrive within the deadline, or some of the transactions with ${\lambda }_F$ to fail to meet the real-time deadline. The variable bulk service is assumed to take place when the number of slots in the mined transactions reaches at every possible number $i$, where $0\le i\le n$, i.e., a bulk processing of multiple transactions in multiple slots between $0$ and $n$, inclusive, for posting in a block. Note that the real-time deadline requirement is considered under the underlying assumption that the size of each block is adaptive, in other words, varying block by block, and the proposed VBAVBS model with ${\lambda }_F$ normalizes the probability for each size of the block throughout.

The paper is organized as follows. In the following section, preliminaries and design-variables for the proposed real-time chain and its performance modeling and analysis are reviewed, and some related works on blockchain dependability [9,11] modeling and analysis are introduced; then, the proposed real-time chain and its analytical model are derived and captured in the context of a queueing system; a section follows in order to demonstrate numerical simulations versus various blockchain-related parameters [10], and results are shown; finally, conclusions are drawn and a discussion completes the last section.

2. Preliminaries and Literature Review

A few key concepts and components of blockchain are listed as follows [4,5,7]. Public Key: Every node/user in the blockchain is assigned a public/private key. A transaction to be made on the blockchain has to be signed by a private key, while the public key is always visible to everyone on the blockchain; transaction: A transaction contains the details of the both the public keys (in case of smart contract [16]—contract address), a hash of the previous block, the current block number and the amount of crypto currency being transferred to, along with the gas needed to execute the transaction; block is a list of transactions recorded into the distributed ledger over time. The transactions are grouped together and put in the block which are then mined to be added to the blockchain. The immutability of the blockchain assures that the transaction once recorded in a block cannot be deleted or undone; chain: All the blocks have a unique block number. The block number is incremented by 1 for every block that is added to the chain. The hash in blockchain is created from the data that was in the previous block. The previous block hash will also be added to the current block details. Thereby, any change in the previous block completely alters the entre hash which would invalidate the blockchain; crypto currency: Ether is the crypto currency in Ethereum blockchain. Any transaction to be posted on the blockchain utilizes the respective crypto currency of the blockchain; gas: The amount of ether needed to post a transaction in Ethereum blockchain. The current blockchain is coded in such a way that the transaction with highest gas fees are given higher priority to be included in the block. This proposed real-time details out different algorithms that can be used to order transactions differently in the block; miner: Nodes that participate in creating a new block are called miners. Miners are responsible for adding blocks to the blockchain. The blocks are created based on the number of transactions present in the txnpool and other characteristics like gas fee, block size, arrival time; transaction pool: Transaction pool is an array datatype of transactions containing the pointers to the transactions that are not yet posted to the block. Pending transactions are the transactions that are not yet posted to the blockchain and these pending transactions reside in the transaction pool [8]. The different ordering of the transaction pool creates different mining [14,15] algorithms [13]; mining: The central process of blockchain-based computing to establish a trust among the nodes in the network connected in a P2P manner. Miners compete for the next new hash code which requires a computationally intensive process and is highly costly. In this context, there have been efforts made extensively to mitigate or eliminate the mining process.

There have been reports on various, yet critical, performance and dependability problems in [17,18,19,20], where extensive research has been conducted on theoretical designs of a few blockchain-based solutions in order to establish a theoretical yet substantial foundation. As the ultimate quality of crypto computing will be determined by its likelihood to be performed as commanded or desired— referred to as the dependability—those theoretical models emphasized and are centered around the dependability of each of those crypto solutions to accommodate such capabilities as the on/off-balanced crypto computing [12,21], the real-time computing [20], the slim-computing [17] and the hybrid computing [18]. A theoretical study on performance is of ultimate interest to identify a theoretical intersection versus the dependability, which is the ultimate objective of the proposed variable bulk arrival and variable bulk service (VBAVBS) model with ${\lambda }_F$ in the context of the proposed real-time chain.

3. Proposed Variable Bulk Arrival and Variable Bulk Service (VBAVBS) Model with ${\lambda }_F$ for Real-Time Chain

In the proposed real-time chain model, an embedded Markovian single-server exponential queueing system (i.e., $M^{1,n}$/$M^{1,n}$/1) is considered without loss of generality, and the server (the server is the equivalent of the group of miners to select the transactions to be posted) serves the entire batch of customers (the customers are the equivalent of the transactions to be posted in the block) in the queue (a queue is the equivalent of a block to be mined and posted) all at once, at the same time. Whenever the server completes a service (a service is the equivalent of a process of posting a block), it then purges the queue (i.e., the equivalence of posting a block) and then serves the influx of new incoming customers. Note that it is assumed that the service takes place within a certain amount of time, yet no transaction is assumed to arrive in the meantime. However, note that it is not unlikely to have new customer arrive if a significant amount of service time is assumed, from a practical point of consideration. It is assumed that the service time is exponential at $\frac{1}{\mu }$ when the server is serving the entire queue of any size between $0$ and $n$, inclusively and equivalently, posting and purging the entire queue. Without loss of generality, it is assumed that customers arrive at an exponential rate of $\lambda$ successfully within the deadline yet, at the rate of ${\lambda }_F$, the customers are assumed to fail to arrive within a specific deadline to meet the real-time requirement. The underlying queueing process is assumed to take place with variable-sized slots and the status of the queue is determined by the number of slots of any size in the current block.

Based on the assumptions above, the proposed VBAVBS model with ${\lambda }_F$ also employs an embedded Markovian queueing model like the VBASBS (Variable Bulk Arrival And Static Bulk Service) in [19], and it defines the states as expressed in terms of the number of slots assigned to a block, and it traces the normalized number of slots allocated for the transactions in steady state rather than the number of transactions whose size varies in the number of slots.

• $P_0$: The state in which no transaction (i.e., no slot) has arrived in the queue as of yet for the posting in the block, currently [19].
• $P_n$: The state in which there are $n$ number of slots (i.e., the capacity of the queue, equivalently, the maximum number of slots set and voted by the miners or voters) arrived in the queue for the posting in the block, currently [19].
• $P_i$: The state in which there are $i$ number of slots (where $0<i<n$) arrived in the queue for the posting in the block, currently [19].

The random variables employed to express the state transition rates are specified as follows.

• $\lambda$: The rate for a slot of a transaction to arrive successfully within the real-time deadline requirement, and the rate for a transaction to arrive is determined by the number of slots allocated for the transaction in a prorated manner such that a transaction with a size of $j$ number of slots arrives at the rate of $j\lambda$, without loss of generality and practicality as well.
• ${\lambda }_F$: The rate for a slot of a transaction to arrive unsuccessfully past the real-time deadline requirement, and at the rate, the state will self-loop without making any state transition. This rate is the unique one to distinguish VBAVBS from VBASBS in which there was no real-time deadline requirement taken into consideration.
• $\mu$: The rate for the slots of the transactions in the entire queue to be posted and purged. Notice that this is a single and unique state transition 1, 2 and 3.

The balance equations for VBAVBS with ${\lambda }_F$ are shown in the following Equations.

$$\left(\lambda +2\lambda +3\lambda +\cdots +n\lambda +{\lambda }_F\right)P_0=\frac{\mu }{n}{P}_1+\frac{\mu }{n-1}{P}_2+\frac{\mu }{n-2}{P}_3+\cdots \frac{\mu }{n-\left(n-2\right)}{P}_{n-1}+\mu P_n$$

(1)

$$\left(\frac{\lambda \left(n\right)\left(n-1\right)}{2}+{\lambda }_F\right)P_0=\mu \left(\frac{1}{n}{P}_1+\frac{1}{n-1}{P}_2+\frac{1}{n-2}{P}_3+\cdots \frac{1}{n-\left(n-2\right)}{P}_{n-1}+P_n\right)$$

(2)

and

$$P_0+P_1+P_2+\dots +P_n=1$$

(3)

Appendix A shows the detailed solving of balance equations. Equations (4) and (5 describe the generalized value of $P_i$.

$$P_i=q_i^{-1}{P}_0\left[{\displaystyle \sum }_{j=1}^{i}j\left[{\displaystyle \sum }_{k=1}^{i-1}\left[{\displaystyle \prod }_{l=1}^{k-1}{q}_l^{-1}\right]\right]k\right]$$

(4)

where,

$$q_i^{-1}={\left(\frac{\lambda \left(n-i\right)\left(n-i+1\right)}{2}+{\lambda }_F+\frac{\mu }{n-i+1}\right)}^{-1}$$

(5)

In the following, a few baseline performance measurements of primary interests in VBAVBS with ${\lambda }_F$ are shown.

• $L_Q$: The average number of customers (i.e., equivalently the average number of transactions) in the queue (i.e., the block currently being mined) [19] with the new $P_i$

  $$L_Q={\displaystyle \sum }_{i=0}^{n}i{P}_i$$

  (6)
• $W_Q$: The average amount of time a customer (i.e., equivalently, a transaction) in the queue (i.e., the block currently being mined) [19].

  $$W_Q=\frac{L_Q}{\mathsf{\lambda }}$$

  (7)
• $W$: The average amount of time a customer (i.e., equivalently, a transaction) in the system (i.e., the transaction pool in the blockchain) [19].

  $$W=W_Q+\frac{1}{\mathsf{\mu }}$$

  (8)
• $L$: The average number of customers (i.e., equivalently, the average number of transactions) in the system (i.e., the transaction pool in the blockchain) [19].

  $$L=\mathsf{\lambda }W$$

  (9)

4. Numerical Analysis

The efficacy of the proposed VBAVBS model with ${\lambda }_F$ is tested and verified through numerical analysis for the $L_Q,W_Q,W$ and $L$ versus $n$ (i.e., size of a block), $\mathsf{\lambda }$ (i.e., successful transaction arrival rate or speed),${\lambda }_F$ (i.e., unsuccessful transaction arrival rate or speed) and $\frac{1}{\mu }$ (i.e., block posting time). Note that fitting the model against real data is not within the scope of the work, instead, various and extensive numerical simulations are conducted as a baseline validation.

Figure 1 plots the average number of customers in system ($L$) versus the number if slots ($n$), for various $\mathsf{\lambda }$ and a $\mu$ (at 1/15).

$L$ versus $n$, for various $\mathsf{\lambda }$ and a $\mu$, are plotted in Figure 1. It is observed that $L$ picks up as $n$ increases, as expected, yet in a near linear manner. Also, it is observed that $L$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

Likewise, Figure 2 shows the average number of customers in system ($L$) plotted against the rate of slots ($\mu$) for various $\mathsf{\lambda }$ and an $n$ (at 10).

It is observed that $L$ declines as $\mu$ increases, as expected. Also, it is observed that $L$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

The following graph plots $L_Q$ versus $n$, for various $\mathsf{\lambda }$ and a $\mu$ (at 1/15).

It is observed in Figure 3 that $L_Q$ picks up as $n$ increases, as expected, yet in a near linear manner. Also, it is observed that $L_Q$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

Average number of customers in queue ($L_Q$) versus rate of slots ($\mu$) is plotted in Figure 4, for various $\mathsf{\lambda }$, and an $n$ (at 10).

It is observed that $L_Q$ declines as $\mu$ increases, as expected. Also, it is observed that $L_Q$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

The following graph plots $W$ versus $n$, for various $\mathsf{\lambda }$ and a $\mu$ (at 1/15).

In Figure 5, it is observed that $W$ picks up as $n$ increases, as expected, yet in a near linear manner. Also, it is observed that $W$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

The following graph plots $W$ versus $\mu$, for various $\mathsf{\lambda }$, and an $n$ (at 10).

In Figure 6, it is observed that $W$ declines as $\mu$ increases, as expected. Also, it is observed that $W$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

Figure 7 plots $W_Q$ versus $n$, for various $\mathsf{\lambda }$ and a $\mu$ (at 1/15).

It is observed that $W_Q$ picks up as $n$ increases, as expected, yet in a near linear manner. Also, it is observed that $W_Q$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

The following graph plots $W_Q$ versus $\mu$, for various $\mathsf{\lambda }$, and an $n$ (at 10).

In Figure 8, it is observed that $W_Q$ declines as $\mu$ increases, as expected. Also, it is observed that $W_Q$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

Equation (10) shows the throughput per block in the presented model.

$$\gamma =\mu P_n=\mu \frac{\lambda }{\mu }\frac{n\left(n+1\right)}{2}{P}_0=\lambda \frac{n\left(n+1\right)}{2}{P}_0$$

(10)

The following graph plots $\gamma$ versus $n$, for various $\mathsf{\lambda }$ and a $\mu$ (at 1/15). Note that $\gamma$ is plotted versus full range of potential $n$ values so that the $\gamma$ at an $n$ represents the normalized $\gamma$ value in the full range up to $n$.

Figure 9 and Figure 10 plot the throughput per block. It is observed that $\gamma$ stays constant throughout, and $P_n$ barely changes throughout.

The following graph plots $\gamma$ versus $\mu$, for various $\mathsf{\lambda }$, a $\mu$ (at 1/15) and a ${\lambda }_F$ (at 0.001).

It is observed that $\gamma$ picks up as $\mu$ increases, as expected. Also, it is observed that $\gamma$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.

The following graph plots $L$ versus ${\mathsf{\lambda }}_F$, for various $\mathsf{\lambda }$, a $\mu$ (at 1/15), and $n$ (at 10).

It is was observed, in Figure 11, that $L$ declines as ${\mathsf{\lambda }}_F$ increases such that as more numbers of transactions (or slots) fail to arrive within the required real-time deadline, less numbers of transactions will be accommodated. Also, it is observed that $L$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher $\mathsf{\lambda }$, as expected.

The following graph plots $L_Q$ versus ${\mathsf{\lambda }}_F$, for various $\mathsf{\lambda }$, a $\mu$ (at 1/15), and $n$ (at 10) in Figure 12.

It is observed that $L_Q$ declines as ${\mathsf{\lambda }}_F$ increases, and as a greater number of transactions (or slots) fail to arrive within the required real-time deadline, a smaller number of transactions will be accommodated. Also, it is observed that $L_Q$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher $\mathsf{\lambda }$, as expected.

The following graph plots $W$ versus ${\mathsf{\lambda }}_F$, for various $\mathsf{\lambda }$, a $\mu$ (at 1/15), and $n$ (at 10).

Figure 13 and Figure 14 plot the average amount of time in the system/queue with respect to rate of unsuccessful arrivals. It is observed that $W$ declines as ${\mathsf{\lambda }}_F$ increases as a greater number of transactions (or slots) fail to arrive within the required real-time deadline, and the amount of time on average that each transaction (or slot) will be waiting in the block prior to posting is reduced. Also, it is observed that $W$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher $\mathsf{\lambda }$, as expected.

The following graph plots $W_Q$ versus ${\mathsf{\lambda }}_F$, for various $\mathsf{\lambda }$, a $\mu$ (at 1/15), and $n$ (at 10).

It is observed, in Figure 14, that $W_Q$ declines as ${\mathsf{\lambda }}_F$ increases as a greater number of transactions (or slots) fail to arrive within the required real-time deadline, and the time on average is reduced in which each transaction (or slot) will be waiting in the block prior to posting. Also, it is observed that $W$ picks up as $\mathsf{\lambda }$ increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher $\mathsf{\lambda }$, as expected.

5. A Demo: Real-time Chain

Implementation of real-time is shown in this section.

Table A1. Configuration settings of Ethereum and other components.

Component	Version
Geth/Ethereum	1.9.11
Architecture	amd64
Go version	go1.14
Operating system	darwin
Nodejs	v12.14.1
web3	1.2.7

in Appendix B shows a detailed list of components used and the version numbers which were modified to create this demo. With deadline time taken into consideration, four transactions are posted at the same time but with random deadline times to simulate the priority to the deadline variable. In the standard Ethereum model, the transactions are sorted based on the price and nonce. The four transactions, if posted in the standard Ethereum model, would be included in blocks in a decreasing order based on price and nonce. In the modified real-time model, the transactions with deadline time closest to the current block are given higher priority. Figures mentioned in this section present an idea of the deadline times and block posting of the four respective transactions.

Figure 15, Figure 16, Figure 17 and Figure 18 show transactions that are posted with random deadline times: 35, 36, 50 and 58. Figure 15 details a transaction that posted with deadline time variable set to 35. The transaction with a gas limit of 3,000,000 is posted in 25th block. Figure 16 shows another transaction with lower gas limit than the one shown in Figure 15. The gas limit of the transaction is 2,000,000, and the deadline time is set to 36. The contract hash and the block number details are shown below, with the transactions being posted in the 26th block.

A transaction with a gas limit higher than 2,000,000 would be given higher priority in the standard Ethereum model. Such a transaction is posted here to highlight the difference in the priorities given to the transactions even though the transactions have a lesser gas limit. Figure 17 shows a transaction that was posted with a gas limit of 4,500,000 and a deadline time of 50. Since the deadline time was higher than both the previous transactions, this transaction is posted in block 37.

Figure 18 shows another such scenario where the gas limit is higher and the deadline time is farther than the current block, which gives the transaction lesser priority. The transaction is posted with a gas limit of 4,000,000 and the deadline time set to 58. The block number that the transaction got posted is the 39th block of the chain.

6. Conclusions and Discussion

This paper has proposed an analytical approach how to design and realize a real-time chain (Ethereum blockchain-based) under a stringent real-time deadline requirement. A new and novel analytical model has been proposed to estimate the performance of the real-time chain in a quantitative manner, referred to as the variable bulk arrival and variable bulk service with ${\mathit{\lambda }}_{\mathit{F}}$ where ${\mathit{\lambda }}_{\mathit{F}}$ is a random variable employed specifically to address the stringent real-time deadline requirement. The variable bulk arrival rate is assumed to vary linearly, proportional to the size of the transactions in a multiple of λ per slot with success to arrive within deadline, and some of the transactions in ${\lambda }_F$ to fail to meet the real-time deadline, and the variable bulk service is assumed to take place when the number of slots in the mined transactions reaches at every possible number $i$, where $0\le i\le n$, i.e., a bulk processing of multiple transactions in multiple slots between $0$ and $n$, inclusive, for posting in a block. Note that the real-time deadline requirement is considered under the underlying assumption that the size of each block is adaptive, in other words, varying block by block, and the proposed VBAVBS model with ${\lambda }_F$ normalizes the probability for each size of the block throughout. Numerical simulations are conducted on Matlab to verify and demonstrate the efficacy of the model and reveal a good agreement with what was expected intuitively as a baseline validation. The primary performance measurements to be taken are $L, L_Q,W_Q,W$ and $\gamma$ versus $n$ (i.e., size of a block), $\mathsf{\lambda }$ (i.e., successful transaction arrival rate or speed),${\lambda }_F$ (i.e., unsuccessful transaction arrival rate or speed) and $\frac{1}{\mu }$ (i.e., block posting time). The simulation results demonstrate the efficacy and validity of the proposed real-time chain in a quantitative manner with respect to the proposed VBAVBS model with ${\lambda }_F$ as far as it is concerned about $L, L_Q,W_Q,W$ and $\gamma$ versus various $n, \mathsf{\lambda },{\lambda }_F, \mu$. It is noteworthy that ${\lambda }_F$, as a real-time-specific random variable, exhibits quite a significant impact on $L, L_Q,W_Q, W$. A demo has been developed to demonstrate a real-time chain with modification on the Ethereum open source Geth 1.9.11.