Block Interval Adjustment
Based on Block Propagation Time in a Blockchain
Masumi Arakawa† and Kazuyuki Shudo†‡†Tokyo Institute of Technology, Tokyo, Japan‡
Kyoto University, Kyoto, Japan

Abstract—Transaction confirmation throughput is one of themost important performance metrics of public blockchains.
Throughput can be improved by shortening the block generationinterval, but that approach could sacrifice security because
shorter intervals increase the fork rate. Our proposed method
improves the throughput by adjusting the block generationinterval to be as short as possible. Part of the nodes observe
the block propagation times over the blockchain network, andthe interval is determined so as not to increase the fork rate. Our
simulation showed the proposed method works as it is supposedto.
Index Terms—blockchain, throughput, block generation interval, block propagation time

I. I NTRODUCTION
Blockchain is a distributed ledger technology proposed by
Satoshi Nakamoto in 2008 as one of the technologies thatmake up the cryptocurrency Bitcoin [1]. Blockchain has beendeveloped and is used in various fields, including cryptocurrencies such as Bitcoin and Ethereum [2], supply chain management and electronic voting. Blockchain makes it possible
to securely manage information without using a centralized
system, even when multiple malicious nodes are participatingin the network. Despite this advantage, blockchain faces somechallenges, including low transaction throughput and long
confirmation time. For example, Bitcoin’s throughput was
initially approximately 7 transactions per second (TPS) andis now reported to be up to about 27 TPS [3], which issignificantly lower than the average throughputs of typicalnon-decentralized payment systems such as Visa and PayPal,
which have throughputs of approximately 1,700 TPS [4] and600 TPS [5], respectively. This low transaction throughputof blockchain causes significant delays in transaction confirmation and a significant increase in transaction fees tohave the transaction processed when demand exceeds theblockchain’s capacity. This is a major problem for blockchain
as a currency or payment system and limits the wide range of
its applications.
These problems can be resolved by shortening the block
generation interval, which is currently fixed in a blockchain,or by increasing the block size to increase the number oftransactions that can be contained in a single block. However,if the block generation interval is shortened so that the blockpropagation time is no longer sufficiently shorter than theblock generation interval, the fork rate will increase. Similarly,
This work was supported by JSPS KAKENHI Grant Number JP21H04872.

increasing block size increases block propagation time andconsequently the fork rate. An increase in the fork rate is undesirable because it worsens security. The fork rate is affected by
the block propagation time and the block generation interval;
the shorter the block generation interval and the longer theblock propagation time, the higher the fork rate is [6]. Blockpropagation times change due to changes in topology, theintroduction of new protocols in blockchain networks, andchanges in Internet bandwidth. For example, according to a
website that monitors the Bitcoin network, block propagation
times have been reduced in recent years [7]. In this situationof shorter block propagation time, it is possible to increase thethroughput without changing the fork rate.
Therefore, we propose a method to adjust the block generation interval based on the block propagation time. The
proposed method adjusts the block generation interval tomaintain the set fork rate, which allows the block generationinterval to be shorter than it currently is, thereby achieving
good throughput while simultaneously maintaining security bykeeping the fork rate within an acceptable range. Moreover,the block generation interval can quickly adjust to changes inthe block propagation time.
Section 2 shows the background and related work of thispaper. Section 3 describes block interval adjustment based onblock propagation time, the proposed method. Section 4 showsthe evaluation results. Finally, Section 5 summarizes the paper.
II. BACKGROUNDThis section provides an overview of block propagation,
forking, throughput, and the block generation interval in a
blockchain; we also describe related research.
A. Block propagation time and forking
In blockchains that use proof-of-work as the consensus
algorithm, new blocks are generated by mining, which entails
competition between nodes, called miners, who try to generate
new blocks. In some blockchains that employ proof-of-stake,new blocks are generated stochastically through competition
among nodes. In a blockchain, which is a distributed system,
data are shared in the system by means of repeated transfers
between nodes, so it takes time from when a new block isgenerated by a node to when it reaches all the nodes throughthe network, and that time is called the block propagation time.
During block propagation, a node that has not yet received
the block continues mining because it does not know that theProc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

block has been generated, and it may generate a different blockof the same height. When multiple blocks of the same heightare generated, the chain splits into multiple branches, which iscalled a fork. The occurrence of a fork is undesirable from asecurity standpoint [8] because it distributes the computational
power of miners, making the blockchain more vulnerable to
51% attack. The fork rate and block propagation time areclosely related, and a study by Decker et al. [6] showed thatwith a fixed block generation interval, the fork rate decreases
as the propagation time decreases. Therefore, a shorter blockpropagation time is preferred.
Various research has been conducted with the aim of
reducing the block propagation time, and various proposals
have been made, such as Graphene [9], which significantly
reduces block size, and mechanisms for selecting neighboring
nodes [10] [11], etc. Real-world blockchains such as Bitcoin
have incorporated research results, and the propagation timeis decreasing [7]. Furthermore, this decrease is due to theintroduction of the compact block relay (CBR) [12] andrelay networks [13] [14]. Changes in Internet bandwidth andthe regional proportions of nodes may also affect the blockpropagation time.
B. Transaction confirmation throughput
A transaction is ”confirmed” when it is included in a new
block. A transaction is further confirmed when a new blockis added after the block to which it belongs. When there area certain number of confirmations (e.g., six for Bitcoin), thetransaction is considered almost certainly secure. The throughput of such confermations is measured in transactions per
second (TPS) and is one of the performance indicators of theblockchain. Simply put, throughput is calculated by dividing
the number of transactions that fit in a single block by theblock generation interval. In practice, the average throughput
is often considered because there are many different types oftransactions of different sizes and the number of transactions
in a single block varies.
While there have been many studies, proposals, and implementations of methods to increase throughput, the simplest
method is to increase the block size and shorten the block generation interval. However, increasing the block size increases
the time it takes to propagate the block, which increases thefork rate unless the propagation speed is increased. Large
blocks may also lead to centralization because individual users
in the network will not be able to propagate blocks efficiently
and it will be difficult to validate a large number of transactions
within a given time period. There is also a problem withthe method of shortening the generation interval, as described
below.
C. Block generation interval
Shortening the block generation interval improves TPS.
However, some studies have shown that shortening the block
generation interval is problematic [8] [15]. The block generation interval and the fork rate are related, and Gervais et al.
showed, using a simulator, that shortening the block generationinterval increases the fork rate of the blockchain [15]. To
shorten the block generation interval without increasing thefork rate and to improve scalability, the block propagation
time must be reduced. This issue also motivates the shorteningof the block propagation time. In practice,the average interval
between block generation is fixed in most existing blockchains.
In Bitcoin, for example, the average block generation interval
is adjusted to 10 minutes by changing the mining difficulty according to the total computing power of the miners. Therefore,
even if the block propagation time is reduced, as is actually
happening with Bitcoin, it does not contribute to improved
scalability.
D. Related work
For long-term use of the blockchain, it is desirable to havea mechanism to adjust the block generation interval or block
size from a scalability perspective. In their study focusing on
fairness among miners, Kanda et al. proposed a method toadjust the block generation interval so that the fork rate reaches
a set value based on the target fork rate and the actual observed
fork rate using the following formula [16].
F orkRatetargetF orkRate(1)
Kanda’s method targets long-term changes in block propagation time, and their simulation experiments confirmed its
long-term effectiveness. However, since a long period of timeis required to observe the fork rate with high accuracy, their
method has the disadvantage that when propagation timechanges quickly, it takes time for the change to be reflectedin the block generation interval. Shortening the time period toaccelerate the response results in large errors and unintended
fluctuations in the block generation interval.
newBlockInterval = oldBlockInterval

III. P ROPOSED METHODThis section describes the block generation interval adjustment method based on block propagation time proposed inthis research.
A. Adjustment method
Let Xb be a random variable of the time between thegeneration of a block and the generation of the next block,and let tb be the block generation interval. The probability Pbof a block being generated in the entire Blockchain network at
any given time is kept constant by adjusting the difficulty ofblock generation, and it can be expressed using tb as follows.
Pb = P r[Xb < t + 1|Xb > t] ≈

1
tb

(2)

When the block generation interval is fixed, changes in propagation time affect the fork rate [6]. Let f (t) be the expectedvalue of the fraction of nodes that have received the block attime t with 0 as the time when the block was generated; thefork rate can be expressed by the following formula using Pb
and f (t) [6].
R∞

P r[F ≥ 1] = 1 − (1 − Pb ) 0 (1−f (t))dt

Proc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

(3)

The equation can be transformed by setting the target fork rate
as Pfork .

B. Propagation time measurement
R∞
To measure 0 (1 − f (t))dt, information on the time atwhich each participating node received the block is required.
For this purpose, all nodes must have common clock information and share the time of block reception. The common clock
can be based on real time and synchronized at each node using
NTP with an external time server as the source, by using GPS
time information, or by introducing a Byzantine fault-tolerant
time synchronization protocol that operates on the blockchain
network. The sharing of receive time information is a new typeof communication, and there is concern that if all nodes share
information, the amount of communication for each node will
increase as the number of nodes increases and the number ofblocks per unit time increases. The additional requirement tosynchronize with a common clock and increased communication costs may increase the difficulty of participating in a
blockchain network, which is undesirable.
Thus, we introduce a method in which a certain numberof nodes with common time information take measurements
and share the result with all nodes. With this method, thedifficulty of participation is solved because the increase incommunication volume is small for nodes that do not participate in the measurement. The measurement results are sharedby all nodes, which requires communication, but methods toimprove efficiency, such as building a distribution tree, can beconsidered.
In both method, an attack such as a malicious node sending
false time information may occur. If this occurs, it will affectthe measurement results and cause the fork rate to deviate
from the set target value. Possible mitigation measures include
excluding time outliers and scoring the nodes participatingin the measurement to eliminate suspicious nodes, but it isdifficult to prevent completely.
IV. EVALUATION
To evaluate the effectiveness of the proposed method, experiments were conducted using a public blockchain simulator,
SimBlock [17]. The main parameters used in the experiments
are shown in Table I. The initial values for internode latency
and bandwidth were the six regional values measured by
Nagayama et al. [18]. The Bitcoin protocol is designed torelay isolated blocks (not main chain blocks) under certain

Number of nodes
Block generation interval
Block size
Compact block size
Percentage of CBR nodes
Bandwidth
Latency

5,000
Variable
534 KB
18 KB
96.8 %
Variable
Values by Nagayama et al. [18]

120

115

accuracy (%)

1 R∞
(4)
Pfork = 1 − (1 − ) 0 (1−f (t))dt
tb
1
R∞
1
(1 − ) = (1 − Pfork ) 0 (1−f (t))dt
(5)
tb
1
tb =
(6)
1
R∞
1 − (1 − Pfork ) 0 (1−f (t))dt
R∞
On the basis of the above equation, once 0 (1 − f (t))dt
is known, the block generation interval can be determined tomatch the set target fork rate.

TABLE IM AIN PARAMETERS USED IN THE EXPERIMENTS .

110

105

100

95

90
0

100

200

300

400

500

number of measurement nodes

Fig. 1. Effect of different numbers of measuring nodes.

circumstances, and SimBlock follows suit. Therefore, in theimplementation of Kanda’s method for observing and comparing fork rates, we modified SimBlock to relay blocks outsideof the main chain under any circumstances to share the fork
rate among the nodes. In the experiment, only a limited number of nodes measured the time of block reception.The nodes
participating in the measurement were selected at random.
A. Effect of different numbers of measuring nodes
To see howRmuch the number of measuring nodes affects∞
the results of 0 (1 − f (t))dt when not all nodes participate
in the measurement, we varied the number of measuring
nodes and observed the change in error. The ratio of theaverage value calculated from the information of all nodes
to the average value calculated from the information of somerandomly selected measuring nodes is shown in Figure 1. For
10 nodes, or 0.2 % of the total number of nodes measured,
the difference from the measurement results at all nodes is14.1 %, resulting in a large error. Increasing the number ofmeasuring nodes to 50 improves the difference to 2.2 %, andat 100 nodes, the difference is only 1.2 %. It can be seenthat even 100 nodes, which is 2% of the total, gives a resultclose to the correct value. In each subsequent experiment, thenumber of measuring nodes was set to 100.
B. Constant bandwidth
Simulations were performed by applying the proposed
method. First, we assessed how the fork rate and block
generation interval change for the proposed method when the
bandwidth between nodes is constant. To clarify the effect,
the initial block generation interval was set shorter so thatthe fork rate would be higher. The target fork rate was set to
5.00 %, and the interval was first adjusted after 4,000 blocks

Proc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

3500030000

40fork rate (%)

25000
30

20000

15000

20

10000
10
5000

0

30

5000

10000

15000

20

15

10

5

0
0

adjusted
not adjusted

25

fork rate (%)

fork rate
block generation interval

block generation interval (msec)

50

0

20000

0

block height

5000

10000

15000

20000

25000

30000

35000

40000

block height

and then adjusted every 1,000 blocks thereafter. In subsequent
experiments, the first adjustment was made at block height
4,000, which is why there are large fluctuations at block height
4,000. Experiments were conducted up to 20,000 blocks, andthe fork rate and block generation interval for every 1,000
blocks are shown in Figure 2. The fork rate was high in thefirst 4,000 blocks before the adjustment began, but after theinterval adjustment was made, the rate remained around theset 5.00 %. The average fork rate for the 16,000 blocks after
the start of the adjustment is 4.90 %, which is close to theset value. The block generation interval was maintained ataround 26,000 milliseconds, although there are some small
fluctuations.

Fig. 3. Fork rate with increasing bandwidth (with CBR).
35000

block generation interval (msec)

Fig. 2. Fork rate and block generation interval with constant bandwidth.

not adjusted
adjusted

30000

25000
20000
15000
10000

5000
0
0

5000

10000

15000

20000

25000

30000

35000

40000

block heightFig. 4. Block generation interval with increasing bandwidth (with CBR).

C. Increasing bandwidth
In the case of increasing bandwidth, we observed the samechanges in the fork rate and block generation interval as inour previous experiments. Experiments were conducted withand without CBR, with the bandwidth set to increase by afactor of 1.4 every 4,000 blocks. As in the constant bandwidthcase, the block generation interval was adjusted with proposed
method, and simulations were performed up to 40,000 blocks.
The results were then compared to those in the case with noadjustment. Likewise, the target fork ratio was set to 5.00%,
with the first adjustment made at a block height of 4,000 and
subsequent adjustments made every 1,000 blocks thereafter.
As the bandwidth increases every 4,000 blocks, the blockpropagation time decreases every 4,000 blocks; therefore, theblock generation interval becomes shorter.
The results are shown in Figures 3, 4, 5, and 6. Without
interval adjustment, the fork rate gradually decreases withincreasing bandwidth. On the other hand, when the proposed
method is used to adjust the spacing, the fork rate is generally
maintained approximately at the set level of 5.00 %. The
average fork rate for the 36,000 blocks after the start of theadjustment is 5.01% with CBR and 4.86% without CBR. The
block generation interval is adjusted to become shorter as the
bandwidth increases and the propagation time decreases. In
the case without CBR, the size of blocks transferred between
nodes is much larger than that in the case with CBR, and theeffect of the bandwidth on the propagation time is greater.
Therefore, the effectiveness of the proposed method is welldemonstrated, and the difference in fork rate between the casewith and without interval adjustment is large.
D. Decreasing bandwidth
In the case of decreasing bandwidth, we also observed
the same changes as in the previous experiments: we set
the bandwidth to decrease by a factor of 0.7 every 4,000
blocks and conducted experiments with and without CBR. The
initial block generation interval was set longer than that inother experiments to reduce the initial fork rate. As before,
the block generation interval was adjusted with the proposed
method, and simulations were run up to 40,000 blocks andcompared to the case with no adjustment. The target fork
rate and the first adjustment are the same as before. As the
bandwidth decreases, the block propagation time increases
every 4,000 blocks; therefore, the block generation interval
becomes longer.
The results are shown in Figures 7, 8, 9, and 10. Without
interval adjustment, the fork rate gradually increases withdecreasing bandwidth. On the other hand, when the proposed
method is used to adjust the interval, the fork rate is generally
maintained at approximately the set level of 5.00 %. The
average fork rate for the 36,000 blocks after the start of theadjustment was 5.25% with CBR and 5.45% without CBR,
slightly higher than the set rate of 5.0%. In the proposed
method, for each 1,000 blocks between the bandwidth change
and the next adjustment, the block generation interval is

Proc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

70

adjusted
not adjusted

20

adjusted
not adjusted

60

15

fork rate (%)

fork rate (%)

50

40

30

10

5

20

10

0
0

0
0

5000

10000

15000

20000

25000

30000

35000

5000

10000

15000

40000

Fig. 5. Fork rate with increasing bandwidth (without CBR).
80000

block generation interval (msec)

block generation interval (msec)

60000

50000

40000

30000

20000

10000

5000

10000

15000

20000

25000

30000

35000

40000

100000
80000
60000
40000
20000
0

40000

0

5000

10000

15000

20000

25000

30000

35000

40000

block heightFig. 8. Block generation interval with decreasing bandwidth (with CBR).

80

adjusted
not adjusted

70

60

fork rate (%)

adjusted based on the propagation time before the bandwidthchange, which sets the generation interval shorter than theideal value. Therefore, in every 1,000 blocks after the bandwidth change, the fork rate exceeds the set value, which is thecause of the deviation from the set value. The graphs showthat after the bandwidth change, the fork rate is higher than
5.00 % for, e.g., blocks 16,000-17,000, 24,000-25,000, and
32,000-33,000. The reason for the larger deviation from thetarget fork rate in the case without CBR is that the effect of
bandwidth changes on the fork rate is larger than that in thecase with CBR. As the incremental bandwidth decreases andthe propagation time increases, the block generation interval
is adjusted to increase every 4,000 blocks.

35000

120000

block heightFig. 6. Block generation interval with increasing bandwidth (without CBR).

30000

not adjusted
adjusted

1400000025000

Fig. 7. Fork rate with decreasing bandwidth (with CBR).

not adjusted
adjusted

70000

20000

block heightblock height

50

40

30

20

10

0
0

5000

10000

15000

20000

25000

30000

35000

40000

block heightFig. 9. Fork rate with decreasing bandwidth (without CBR).

E. Comparison with existing method
not adjusted
adjusted

1.6x106

block generation interval (msec)

A comparison was made with the method of adjusting theblock generation interval based on the fork rate by Kanda
et al [16]. Experiments were conducted up to a block heightof 24,000, with the bandwidth set to decrease by a factor of
0.1 at a block height of 8,000 and then return to a factor of
1.0 at a block height of 16,000. CBR was not used in thisexperiment, and the target fork rate and the first adjustment
are the same as before, 5.00 % and 4,000 blocks, respectively.
The adjustment interval was set to 500 blocks for the proposed
method and 500, 1,000, and 2,000 blocks for the method of
Kanda et al. The results are shown in Figures reffig:compare
and reffig:compare. When the bandwidth decreases at a blockheight of 8,000, there is a temporary increase in the fork rate

1.4x106

1.2x106

1x106

800000600000400000200000

0
0

5000

10000

15000

20000

25000

30000

35000

40000

block heightFig. 10. Block generation interval with decreasing bandwidth (without CBR).

Proc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022

50

proposed method
Kanda method (500)
Kanda method (1000)
Kanda method (2000)

fork rate (%)

40

30

20

R EFERENCES

10

0
0

5000

10000

15000

20000

block heightFig. 11. Comparison of fork rate when the bandwidth changes.
800000

proposed method
Kanda method (500)
Kanda method (1000)
Kanda method (2000)

block generation interval (msec)

700000600000500000400000300000200000100000

0
0

5000

10000

15000

20000

block heightFig. 12.
changes.

of the proposed method was confirmed and compared withthat of existing methods using a simulator.
Future work will include improving the detailed method
for measuring propagation time and investigating methods foraddressing malicious nodes.

Comparison of block generation intervals when the bandwidth

for all methods, but the shorter the adjustment interval is, themore quickly the fork rate is adjusted to approach the set
rate of 5.00 %. When the bandwidth is restored at a blockheight of 16,000, there is a similar temporary decrease in
the fork rate, but again, the shorter the adjustment interval
is, the more quickly it returns to normal. Moreover, for theblock generation interval, the shorter the adjustment interval
is, the shorter the time between the bandwidth change and thecorresponding adjustment of the generation interval. Shorter
adjustment intervals are better at following changes in propagation time. On the other hand, looking at the fluctuationsin the block generation interval, in the proposed method, thegeneration interval remains constant when the bandwidth isconstant. By contrast, Kanda et al.’s method inadvertently
raises or lowers the generation interval when the adjusting
interval is short. As a result, the variability of the fork rate
also increases.
V. C ONCLUSION[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[2] G. Wood, “Ethereum: A secure decentralised generalised transaction
ledger EIP-150 REVISION.”[3] E. Georgiadis, “How many transactions per second can bitcoin reallyhandle ? theoretically,” IACR Cryptol. ePrint Arch., vol. 2019, p. 416,
2019.
[4] Visa, https://usa.visa.com.
[5] “PayPal,
Inc—
PayPal
Q3-21
Investor
Update,”https://investor.pypl.com/.
[6] C. Decker and R. Wattenhofer, “Information propagation in the Bitcoin
network,” in IEEE P2P 2013 Proceedings, 2013, pp. 1–10.
[7] “Bitcoin Network Monitor - DSN Research Group, KASTEL @ KIT,”
https://dsn.tm.kit.edu/bitcoin/, Accessed: Dec. 26. 2021.
[8] Y. Sompolinsky and A. Zohar, “Secure High-Rate Transaction Processing in Bitcoin,” in Financial Cryptography and Data Security 2015
(FC15), R. Böhme and T. Okamoto, Eds., 2015, pp. 507–527.
[9] A. P. Ozisik, G. Andresen, B. N. Levine, D. Tapp, G. Bissias, and
S. Katkuri, “Graphene: efficient interactive set reconciliation applied toblockchain propagation,” in Proceedings of the ACM Special Interest
Group on Data Communication, 2019, pp. 303–317.
[10] Y. Aoki and K. Shudo, “Proximity Neighbor Selection in Blockchain
Networks,” in Proc. 2nd IEEE International Conference on Blockchain(IEEE Blockchain 2019),, 2019, pp. 52–58.
[11] H. Matsuura, Y. Goto, and H. Sao, “Region-based Neighbor Selectionin Blockchain Networks,” in Proc. 2021 IEEE International Conference
on Blockchain (IEEE Blockchain 2021), 2021, pp. 21–28.
[12] M.
Corallo,“Compact
Block
Relay
(BIP-152),”
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki.
[13] R. Nagayama, R. Banno, and K. Shudo, “Identifying impacts of protocol
and internet development on the bitcoin network,” in 2020 IEEE
Symposium on Computers and Communications (ISCC). IEEE, 2020,
pp. 1–6.
[14] K. Otsuki, R. Banno, and K. Shudo, “Quantitatively Analyzing Relay Networks in Bitcoin,” in 2020 IEEE International Conference on
Blockchain (Blockchain). IEEE, 2020, pp. 214–220.
[15] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and
S. Capkun, “On the Security and Performance of Proof of Work
Blockchains,” in Proceedings of the 2016 ACM SIGSAC Conference
on Computer and Communications Security, ser. CCS ’16. New
York, NY, USA: Association for Computing Machinery, 2016, p. 3–16.
[Online]. Available: https://doi.org/10.1145/2976749.2978341[16] R. Kanda and K. Shudo, “Block Interval Adjustment Toward Fair Proofof-Work Blockchains,” in 2020 IEEE 36th International Conference on
Data Engineering Workshops (ICDEW). IEEE, 2020, pp. 1–6.
[17] Y. Aoki, K. Otsuki, T. Kaneko, R. Banno, and K. Shudo, “SimBlock:
A Blockchain Network Simulator,” in IEEE INFOCOM 2019 - IEEE
Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2019, pp. 325–329.
[18] R. Nagayama, K. Shudo, and R. Banno, “Simulation of the Bitcoin Network Considering Compact Block Relay and Internet Improvements,”
IEICE Technical Report; IEICE Tech. Rep., vol. 119, no. 460, pp. 179–
183, 2020.

Scalability is one of the major challenges in blockchain.
This paper proposes a method to adjust the block generationinterval based on the block propagation time. By focusing on
the close relationship between the block generation interval,
fork generation rate, and block propagation time, the proposed
method makes it possible to adjust the block generation interval to maintain the fork rate. This prevents the deteriorationof security caused by an increase in the fork rate, while
maximizing the improvement in scalability. The effectivenessProc. 5th IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2022), August 2022