5.1. Experimental Environment
The Cosmos Hub Client (Gaia Client) and the Osmosis Client were the foundation for deploying the measurement nodes used in this study. The device on which the measurement nodes are installed meets the minimal hardware requirements of each client. This study’s computer has the following specifications: an Intel Xeon Silver processor, 128 GB of RAM, and Linux 18.04. It also has adequate capacity to fulfill the synchronization demands of Osmosis and Cosmos Hub, with 5 T.B. HDDs.
The Cosmos Hub Client (version 7.0.2), Osmosis Client (version 8.0.0), and Go-Language (version 1.18.2) are all part of the measurement nodes’ software environment. The Cosmos Hub installed Version 3.0.0 of the IBC-GO module, which facilitates communication across blockchains, whereas Osmosis has Version 2.0.2 loaded.
The measurements were collected during 24 h, from 1 June to 2 June 2022. The fungible tokens were moved from the mainnet of Osmosis to the mainnet of Cosmos Hub. Each token transfer necessitated the transmission of 1000 bits plus a 260-bit transaction fee. Token transfers were performed every 86.4 s for 1000 transactions every day.
5.2. Results of Measuring IBC Msg Relay Time
The IBC message relay time data was modified to address its perceived length, which may have distorted the concentration tendency.
Figure 13 illustrates Cosmos’s IBC message relay time before outliers are removed. The top three data points (message relay time) are 371.886, 285.052, and 198.265 s. The boxplot, as shown in
Figure 14, shows that these three data points are extensively apart compared to the total data distribution. Outliers were found in fungible token transfers with the sequence numbers 1029737, 1029741, and 1029744 between channel-141 and channel-0, which connects the Cosmos Hub and Osmosis. Valid IBC Recv Tx and Valid IBC Ack Tx outliers occurred within blocks of the same height.
The block-generating times for Cosmos Hub and Osmosis remained constant during the outlier occurrence at the typical block-generation time. Furthermore, the Round value in the block data, representing the number of times the relevant height block was revoted, was 0 [
17]. Analysis shows that the three outliers faced delays in the relay process rather than in each blockchain’s consensus process. The cause of the IBC message relay time delay deserves additional investigation. As a result, this study removes outliers from the dataset, refines the data, and performs statistical analysis.
Figure 15 shows the ordered IBC message relay timings, which compute the time from Generation_time to Ack_time of the IBC Msg Relay Time data. The longest time for an IBC message relay is 138.662 s, while the minimum duration is 28.176 s. The message relay process takes roughly 55.448 s on average. The median value is 52.153 s, which is close to the average, showing that the IBC message relay time data is distributed evenly.
The minimum value of G to T time was taken to be 0 in order to synchronize the time zones of the Cosmos hub and the Measurement Node by adding −13.081 to the minimum value of Generation_time. Given the low variance and standard deviation of the T to R time section, the data are concentrated around the mean. Furthermore, the message delivery in R to A time section was approximately higher than in other time sections. As a result, the T to R time will be supplied at an average of 13 s, while R to A time will be slower than other time sections. Transactions are transmitted from the Cosmos Hub and incorporated in blocks at G to T time. The G to T time is the same as the transaction processing procedure in the blockchain, with the only difference being the kind of transaction. The in-chain transaction processing time in the Cosmos Hub is estimated as G to Time.
By adding the value of the minimum G to T time (−13.081) to the Generation_time, the minimum G to T time was set to 0. The parallax between the Measurement Node and the Cosmos Hub was aligned with this correction. Given the low variance and standard deviation of the T to R time section, the data are concentrated around the mean. The message delivery in R to A time section was approximately
longer than in other time sections, which implies that in the T to R time section, a transaction is expected to be transmitted in an average of 13 s, while in the R to A time section, the delivery time will be slower than other sections. Transactions are transmitted from the Cosmos Hub and incorporated in blocks at G to T time section. Regardless of transaction type, the G to T time represents transaction processing time within the Cosmos Hub blockchain.
Table 3 shows the findings of the distribution of IBC time.
5.3. Results of Analysing IBC Msg Relay Time
The histogram of experimental values is skewed to the left, showing a deviation from the normal distribution, as presented in
Figure 16. To address this, we assumed that the related graph had a lognormal distribution because values cannot be smaller than 0. We modified the natural logarithm on the experimental, focusing on a visually similar trend for the log-transformed message relay time and the lognormal distribution, as shown in
Figure 17.
Numerical tests such as the Kolmogorov–Smirnov test, the Shapiro–Wilk test, and the Anderson–Darling test were used to test whether the previously mentioned graph follows a normal distribution. The null hypothesis said that the data follows a normal distribution, whereas the alternative hypothesis stated that it did not. The Kolmogorov–Smirnov test yielded a p-value of 0.839, suggesting that we cannot reject the null hypothesis because it is above the significance level of 0.05. Similarly, the Shapiro–Wilk test produced a p-value of 0.073, which was likewise over the significance level, implying that the null hypothesis was accepted. Furthermore, the Anderson–Darling test supported the null hypothesis because the estimated statistic of 0.362 was less than the critical values at the selected significance levels [0.574, 0.653, 0.784, 0.914, 1.088]. As a result, we can conclude that the experimental data are consistent with a lognormal distribution. The standard normal distribution table was used to obtain the values corresponding to the probability of 68.3%, 95.4%, and 99.7% for Z-scores of 1, 2, and 3, respectively, because the IBC message relay time distribution follows a lognormal distribution. The correlation coefficients were calculated to analyze the relationship between IBC Msg Relay Time and the time for each subsequent session. The relay of IBC Acknowledgement transactions during the R to A time interval exhibited the highest correlation of all the time intervals.
Several numerical tests assessed whether the acquired findings followed a normal distribution, including the Kolmogorov–Smirnov, Shapiro–Wilk, and Anderson–Darling tests. The null hypothesis assumed a normal distribution, while the alternative hypothesis indicated a deviation from normality. The Kolmogorov–Smirnov test results show that the null hypothesis cannot be rejected because the computed
p-value of 0.839 is above the significance level of 0.05. Similarly, the Shapiro–Wilk test produces a
p-value of 0.073, more than the significance criterion. As a result, the null hypothesis cannot be rejected in this test either. Furthermore, as indicated in
Table 4, the Anderson–Darling test does not give enough evidence to reject the null hypothesis because the calculated statistic of 0.362 is less than the crucial values of [0.574, 0.653, 0.784, 0.914, 1.088]. Based on these findings, it is possible to conclude that the experimental data follow a lognormal rather than a normal distribution.
Because the IBC message relay time distribution is lognormal, the probabilities corresponding to Z-values of 1, 2, and 3 are often employed and reflect about 68.3%, 95.4%, and 99.7% of the data, using standard normal distribution standards.
Table 5 displays the IBC message relay time range per stage.
A correlation study explored the relationship between the IBC Msg Relay Time and the time by section. The correlation coefficient quantifies the strength and direction of a two-variable linear relationship. According to the analysis in
Table 6, the portion with the highest degree of correlation is the R to A time, which indicates the time it takes for the IBC Acknowledgement transaction to be transmitted; this suggests that the IBC Msg Relay Time and the R to A time have a strong linear relationship. The correlation coefficient, which ranges from −1 to 1, assesses the strength of this link. A number near 1 indicates a strong positive connection, implying that as the IBC Msg Relay Time increases, so does the R to A time. On the other hand, a number close to −1 suggests a high negative correlation, meaning that as the IBC Msg Relay Time increases, so does the R to A time. The exact correlation coefficient value would need to be provided to identify the specific degree and direction of the correlation between the IBC Msg Relay Time and the R to A time.
Figure 18 displays the scatter plot association between the IBC Msg Relay Time and the R to A time. The scatter plot’s transparency was set to 0.1 to visualize the distribution of data points. According to the scatter plot, the data points follow a slope near one, demonstrating a strong positive association between the IBC Msg Relay Time and the R to A time. The inclusion of a trend line adds to this insight. The slope of the trend line is 0.957, which is very near to one, showing a strong correlation between the two variables.
Furthermore, the correlation coefficient of 0.73, more significant than 0.7, demonstrates the substantial link between the R to A time amongst blockchains; this implies that the R to A time increases when the IBC Msg Relay Time increases. The T to R time, on the other hand, has a correlation coefficient of 0.215, indicating a lesser link with overall performance; this means that the T to R time has little effect on the overall relationship between message delivery time and R to A time. Our scatter plot study results corroborate the notion that there is a strong link between the IBC Msg Relay Time and the R to A time, emphasizing the necessity of efficient message delivery for avoiding delays in inter-blockchain communication.