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
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.,
, where
is the number of slots across all the mined transactions, and variable bulk service of transactions in exponential time, i.e.,
, for posting in the current block, namely, variable bulk arrival and variable bulk service (VBAVBS) model with
, where
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
; 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
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
, where
, i.e., a bulk processing of multiple transactions in multiple slots between
and
, 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
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.
3. Proposed Variable Bulk Arrival and Variable Bulk Service (VBAVBS) Model with for Real-Time Chain
In the proposed real-time chain model, an embedded Markovian single-server exponential queueing system (i.e., //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 when the server is serving the entire queue of any size between and , inclusively and equivalently, posting and purging the entire queue. Without loss of generality, it is assumed that customers arrive at an exponential rate of successfully within the deadline yet, at the rate of , 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
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.
: 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].
: The state in which there are
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].
: The state in which there are
number of slots (where
) 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.
: 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 number of slots arrives at the rate of , without loss of generality and practicality as well.
: 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.
: 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
are shown in the following Equations.
and
Appendix A shows the detailed solving of balance equations. Equations (4) and (5 describe the generalized value of
.
where,
In the following, a few baseline performance measurements of primary interests in VBAVBS with are shown.
: 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
: The average amount of time a customer (i.e., equivalently, a transaction) in the queue (i.e., the block currently being mined) [
19].
: The average amount of time a customer (i.e., equivalently, a transaction) in the system (i.e., the transaction pool in the blockchain) [
19].
: 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].
4. Numerical Analysis
The efficacy of the proposed VBAVBS model with is tested and verified through numerical analysis for the and versus (i.e., size of a block), (i.e., successful transaction arrival rate or speed), (i.e., unsuccessful transaction arrival rate or speed) and (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 (
) versus the number if slots (
), for various
and a
(at 1/15).
versus
, for various
and a
, are plotted in
Figure 1. It is observed that
picks up as
increases, as expected, yet in a near linear manner. Also, it is observed that
picks up as
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 (
) plotted against the rate of slots (
) for various
and an
(at 10).
It is observed that declines as increases, as expected. Also, it is observed that picks up as increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.
The following graph plots versus , for various and a (at 1/15).
It is observed in
Figure 3 that
picks up as
increases, as expected, yet in a near linear manner. Also, it is observed that
picks up as
increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.
Average number of customers in queue (
) versus rate of slots (
) is plotted in
Figure 4, for various
, and an
(at 10).
It is observed that declines as increases, as expected. Also, it is observed that picks up as increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.
The following graph plots versus , for various and a (at 1/15).
In
Figure 5, it is observed that
picks up as
increases, as expected, yet in a near linear manner. Also, it is observed that
picks up as
increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.
The following graph plots versus , for various , and an (at 10).
In
Figure 6, it is observed that
declines as
increases, as expected. Also, it is observed that
picks up as
increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.
Figure 7 plots
versus
, for various
and a
(at 1/15).
It is observed that picks up as increases, as expected, yet in a near linear manner. Also, it is observed that picks up as increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.
The following graph plots versus , for various , and an (at 10).
In
Figure 8, it is observed that
declines as
increases, as expected. Also, it is observed that
picks up as
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.
The following graph plots versus , for various and a (at 1/15). Note that is plotted versus full range of potential values so that the at an represents the normalized value in the full range up to .
Figure 9 and
Figure 10 plot the throughput per block. It is observed that
stays constant throughout, and
barely changes throughout.
The following graph plots versus , for various , a (at 1/15) and a (at 0.001).
It is observed that picks up as increases, as expected. Also, it is observed that picks up as increases, as expected. Notice that the intervals in between the plots are quite proportionally spaced.
The following graph plots versus , for various , a (at 1/15), and (at 10).
It is was observed, in
Figure 11, that
declines as
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
picks up as
increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher
, as expected.
The following graph plots
versus
, for various
, a
(at 1/15), and
(at 10) in
Figure 12.
It is observed that declines as 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 picks up as increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher , as expected.
The following graph plots versus , for various , a (at 1/15), and (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
declines as
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
picks up as
increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher
, as expected.
The following graph plots versus , for various , a (at 1/15), and (at 10).
It is observed, in
Figure 14, that
declines as
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
picks up as
increases, as expected. Notice that the intervals in between the plots are spaced narrower at higher
, as expected.
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 where 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 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 , where , i.e., a bulk processing of multiple transactions in multiple slots between and , 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 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 and versus (i.e., size of a block), (i.e., successful transaction arrival rate or speed), (i.e., unsuccessful transaction arrival rate or speed) and (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 as far as it is concerned about and versus various . It is noteworthy that , as a real-time-specific random variable, exhibits quite a significant impact on . A demo has been developed to demonstrate a real-time chain with modification on the Ethereum open source Geth 1.9.11.