Inter-Blockchain Communication Message Relay Time Measurement and Analysis in Cosmos ^†

Featured Application

This study’s main application is to improve blockchain interoperability. We can find opportunities for optimization and enhancement in inter-blockchain protocols by examining the performance of inter-blockchain message transfer in Cosmos. This helps to establish more efficient and smooth communication between multiple blockchain networks, opening new possibilities for decentralized apps and cross-chain transactions.

Abstract

This research presents a novel method to assess inter-chain message relay time in the Cosmos blockchain network, which employs the Inter-Blockchain Communication (IBC) protocol for blockchain interoperability. While inter-chain transactions in Cosmos lag behind intra-chain transactions, this research conducts a thorough performance evaluation, emphasizing message relay time across diverse Cosmos chains. The results show a strong association between inter-chain transaction frequency and overall transaction processing speed (TPS), underscoring the inherent trade-off between scalability and compatibility in inter-chain communication protocols. A thorough understanding of inter-chain transaction performance is essential for advancing interoperability and improving cross-blockchain network designs. As a result, this research improves our understanding of Cosmos’ functionality and provides insightful recommendations for boosting the effectiveness and scalability of inter-chain communication. The study also sheds light on message delivery patterns in the Cosmos ecosystem, showing that IBC message relay time has an average duration of 55.448 s and is distributed lognormally. Notably, the time between the commitment of the IBC RecvPacket transaction and the commitment of the IBC Acknowledgement transaction (R to A time) considerably impacts the effectiveness of message transmission, which causes delays in the IBC message relay process.

1. Introduction

1.1. Research Background and Necessity

Blockchain technology, first employed in Bitcoin, has been embraced by various other firms because of its decentralization and security benefits. However, blockchain fragmentation is a problem caused by the proliferation of isolated blockchains. Each blockchain operates independently and cannot do cross-platform transactions or instant communication. This issue highlights the need for heterogeneous blockchain interoperability (HBI) to develop a shared ecosystem. Cosmos [1] overcomes this challenge by employing the Inter-Blockchain Communication (IBC) protocol to connect separate blockchains.

Unlike other heterogeneous blockchains [2,3,4,5,6], Cosmos uses parallel blockchains and Inter-Blockchain Communication (IBC) to address scalability, governance, and energy efficiency concerns. The IBC protocol allows the Cosmos Network of 35 blockchains to connect, facilitating token transfers, data exchange, and blockchain interoperability [7,8,9]. However, as cross-chain connections increase, the network’s overall transaction per second (TPS) may decrease. Inter-blockchain communication protocols must be modified to improve performance, scalability, and compatibility. This study aims to address these challenges by measuring and increasing the efficiency of message transportation across blockchains in the Cosmos.

1.2. Research Objectives

This research aims to achieve the following objectives:

• Describe in detail the Cosmos Inter-Blockchain Communication (IBC) protocol.
• Develop a method for calculating the delivery time of inter-blockchain messages.
• Analyze the measured data statistically, focusing on the distribution of message delivery times.
• Compute the inter-blockchain message delivery time for the Cosmos ecosystem.
• Determine the probability density of variables using correlation analysis and the kernel density function and lognormal distribution.

The study seeks to increase Cosmos’ inter-blockchain communication protocols and improve the ecosystem’s blockchain interoperability performance by attaining these objectives.

1.3. Organization of the Paper

This paper is structured as follows. Section 1 outlines blockchain interoperability technology, Cosmos, and the need for study and its objectives. Section 2 describes the inter-blockchain communication protocols and blockchain interoperability solutions. The suggested framework for evaluating message transport time between blockchains in Cosmos is described in Section 3. Section 4 and Section 5 present the measured message delivery time between blockchains and the analysis findings. Section 6 discusses the findings and future study directions. Section 7 brings the paper to a close.

2. Related Work

This section discusses the interoperability characteristics of the Inter-Blockchain Communication (IBC) protocol, which enables communication and value transfer between various blockchains within the Cosmos ecosystem. The section also emphasizes how Zones and a Hub help to facilitate scalability and interoperability while preserving the autonomy of individual blockchains. The transport and application layers of the IBC protocol are presented, displaying its capacity to provide coordinated and safe data transmission between heterogeneous chains.

2.1. Cosmos Interoperability

2.1.1. Cosmos Structure

Cosmos [1,10] provides a shared environment that promotes interoperability and scalability by allowing various blockchains to communicate and interact. Cosmos’ blockchains are generated independently and concurrently. This new structure allows individual blockchains inside the Cosmos ecosystem to keep their independence while benefiting from horizontal scaling and rapid transaction processing.

As shown in Figure 1, Cosmos’ two essential components are Zones and a Hub, which enable interoperability between heterogeneous blockchains. In this arrangement, Zones represent independent blockchains with their characteristics. In contrast, the Hubs represent central servers that track each Zone’s most recent state. This method ensures frictionless token and data transmission between Zones via the Hub while maintaining global consistency of token numbers across the Cosmos network.

The Inter-Blockchain Communication (IBC) protocol [11,12] allows Cosmos’ different blockchains to interact securely and selectively. IBC allows critical data to flow while maintaining security and privacy. It is compatible with Tendermint-based blockchains such as Cosmos Hub, Osmosis, Evmos, and Juno. Furthermore, blockchains, such as Bitcoin and Ethereum [13] which are not built on Tendermint, can be linked to Cosmos via particular PEG zones. PEG zones enable Cosmos and blockchains from other chains to interact and communicate across chains.

2.1.2. Inter-Blockchain Communication

The end-to-end IBC protocol allows independent blockchains to communicate and transfer value by relaying messages between them. The IBC protocol employs several consensus techniques and state machines. The primary goal of IBC is to enable diverse networks to connect and exchange value, particularly tokens, without intermediaries. IBC ensures that communication between heterogeneous chains is trustworthy, coordinated, and validated.

The IBC protocol’s transport and application layers are distinct. The transport layer must deliver, authenticate, and sort data packets via IBC between blockchains. There are no rules or specifications about the data type that should be delivered or how the receiving chain should perceive this layer. Its constituents include light clients, Relayers, connectors, and channels. To verify block headers, blockchain light clients communicate data with full nodes. Full nodes are high-performance computer and storage devices that allow blockchains to communicate without intermediaries. Channels transfer data across modules, and connections connect light clients on different chains. Relayers are permissionless; users can obtain data packet hashes from the destination chain’s state machines using them. Tokens, NFTs, and Oracle are examples of user-facing application layers that employ the transport layer. The IBC protocol’s ICS-20 token standard describes the format of data packets and how receiver chains should understand them. For example, data packets for token transfers include information about the sender, receiver, token quantity, and denomination. Like a postal delivery system, the IBC protocol’s transport layer connects numerous blockchains without divulging their contents or intended use. The application layer processes the IBC protocol’s data packets, including information on the chains’ transmission and receiving, including the channels’ I.D.

Figure 2 depicts an inter-blockchain communication mechanism for transferring a fungible coin from heterogeneous blockchain A to blockchain B. Transferring an IBC token from the Application Layer of a transmitting node on Blockchain-A to the receiving wallet address on Blockchain-B is requested. The information provided when the IBC layer gets the request is used to determine the receiving wallet address, the receiving wallet address, and the sending wallet address. After receiving the request to construct an IBC Transfer transaction, the IBC layer inputs the sending wallet address, receiving wallet address, tokens, token unit, sending port, sending channel, timeout block height, timestamp, and sequence.

A sequence is a single transaction representing the total transactions produced through a particular channel since the genesis block. The sequence value for all inter-blockchain communication transactions for a specific transaction is the same [9]. The IBC Transfer layer delivers IBC Transfer transactions to peers linked to the transmitting node. The token linked with the IBC Transfer transaction in Blockchain-A becomes locked once the transaction has been validated and incorporated into a block. Messages are not transmitted between blockchains directly in a blockchain-to-blockchain communication architecture. Instead, they generate messages that must be transferred and physically relay them from the sending blockchain to the receiving blockchain via a relay [14].

Relayers are in charge of transmitting inter-blockchain communication transactions and regularly checking the state of blockchains that use IBC protocols. Relayers consolidate and package inter-blockchain communication transactions before transmitting them to the recipient Blockchain-B through IBC RecvPackets. Before being committed, the inter-blockchain communication transaction is confirmed on the receiving blockchain using the IBC layer’s Light Client. After the IBC RecvPacket transaction on Blockchain-B is completed, a voucher is generated and given to the recipient’s wallet. Anyone can run a relay, and depending on the blockchain, they may be rewarded with transaction fees.

The Relayer additionally arranges and broadcasts an IBC Acknowledgement transaction to ensure the token transfer has been completed on the receiver’s blockchain. The IBC Acknowledgement transaction is included in the sender’s block, Blockchain-A’s block, as proof that the token transfer was successful. The Cosmos’ inter-blockchain communication protocol is represented in Figure 2. In contrast, Figure 3 shows a Sequence diagram of the above-described mechanism from steps 1 through 12-1 and 12-2 (as shown in Figure 2).

Inter-blockchain communication protocols must manage instances when transactions are not sent on time or to their destination because they operate across a distributed network and rely on possibly untrustworthy Relayers to relay messages. Suppose an IBC RecvPacket fails to be included in a block unexpectedly, then in that case, the Relayer generates and forwards an IBC Timeout transaction. As soon as the transmitting blockchain receives the IBC Transfer transaction, it begins the Token Unlock procedure.

Table 1. Cosmos IBC transactions.

Transaction Types	Description
IBC Transfer	Locking of the Handling Token in the Sending Chain
IBC RecvPacket	Proof of token lock completion on the transmitting chain and token transfer to the receiving chain
IBC Acknowledgement	The receiving chain’s proof of token receipt and token transfer completion response to the sender chain
IBC Timeout	Failure of token transfer response to sending chain

lists the types of transactions within the Cosmos IBC protocol.

3. Data Collection and Methodology

3.1. Proposed Framework

This section describes the mechanism for collecting message delivery times between the Osmosis and Cosmos Hub blockchains. It also explains the proposed tracking approach, which would link inter-blockchain messages via fungible token transfers in the aggregated transactions. The proposed framework for tracking message delivery times between blockchains is depicted in Figure 4.

Each blockchain’s mainnet [15] is linked to the Cosmos Hub and Osmosis clients, which synchronize to update the ledger information. These clients function in each network just like any other node. The Cosmos Hub client transmits IBC Tx by frequently sending a fungible token [16] based on the IBC to the wallet address of the Osmosis client. These fragmented transactions are confirmed using inter-blockchain Relayer message filtering and tracking, and the message delivery time between these blockchains is determined for each fungible token transmission.

The measurement node, which gathers and examines inter-blockchain message delivery times inside the Cosmos network, is an essential part of the proposed framework. Its primary goal is to measure how long it takes messages to travel across various blockchains, giving important information about how well the Inter-Blockchain Communication (IBC) protocol is working. The measurement node consists of two nodes serving as clients within the Cosmos network. The first node is connected to the Cosmos Hub, while the second node is linked to the Osmosis client, representing different blockchains. These connections enable the measurement node to retrieve the latest blockchain data, including transaction details. Obtaining IBC Tx Generation, IBC Transfer, IBC Recv, and IBC Ack data—which reflect inter-blockchain communication between the Cosmos Hub and Osmosis—requires requesting specific transaction data using RPC commands like “gaiad” and “osmosisd”. Once the data has been gathered, the node processes and analyzes it to determine the inter-blockchain message delivery time and evaluate the effectiveness of the IBC protocol. To comprehend the total distribution of message delivery durations and correlations between time intervals, statistical approaches like kernel density estimation and lognormal distribution analysis are used, exposing performance characteristics of inter-blockchain communication in Cosmos. The measurement node is crucial to understanding IBC protocol performance and enabling further investigation and advancements for the scalability and interoperability of the Cosmos ecosystem.3.2 Transaction Database.

Figure 5 depicts the seven transaction databases used in Cosmos to measure message transit time between blockchains. The hash and propagation start time of fungible token transfer transactions generated by the Measurement Node’s IBC Tx Generation Controller comprise the IBC Tx Generation data. The IBC Transfer Tx data capture transactions that include the requested fungible token transfer transactions from the IBC Tx Generation Controller in the Cosmos Hub’s blockchain through a consensus process. The IBC Transfer Tx data contains transactions with matching hashes from the IBC Tx Generation data. The IBC Recv Tx data reflects transactions added to the Osmosis blockchain following the relay processing of the IBC Transfer Tx data. Transactions processed by the relay and included in the Cosmos Hub blockchain are represented as IBC Ack Tx data. Because relayed transactions are included in blocks, IBC Recv Tx and IBC Ack Tx contain valid and invalid transaction data. Valid IBC Recv Tx and Valid IBC Ack Tx contain data that the Valid Tx Filtering process has validated. The IBC Msg Relay Time data is collected by aggregating time data in the Sequence Tracker merely by tracking the connectivity of a given fungible token transfer operation. The presence of IBC Tx Generation data and matching Valid IBC Ack Tx data ensure that the relevant fungible token transfer was completed successfully, allowing aggregation of message interval delivery time.

These transaction data points assist the Cosmos Measurement Node in tracking and analyzing the time it takes for messages to transit across blockchains, exposing information on the efficacy and performance of inter-blockchain communication.

3.2. Message Collection Structure

3.2.1. Control Process for Transaction Creation

Some components installed on the Measurement Node to manage transaction formation in the study included the Cosmos Hub Client [17,18], Osmosis Client [19], and an IBC Tx Generation Controller. After receiving the request, the Cosmos Hub Client creates an IBC Transfer transaction and displays the transaction information. The IBC Tx Generation Controller uses the Osmosis wallet, which stores the key inside the Cosmos Hub client to request the transfer of fungible tokens from the Cosmos Hub wallet. Every transaction transfer 1000 UATOM (1 ATOM = 1,000,000 UATOM) from the Cosmos Hub to Osmosis. The transaction data is saved as IBC Tx Generation data, and the IBC Tx Generation Controller reviews it before beginning a transaction propagation instruction; this mechanism was repeated 1000 times in 24 h, with breaks of 86.4 s. Figure 6 shows the transaction generation control mechanism.

The unconfirmed transactions are stored in the Cosmos Hub’s mempool of full nodes. Concurrently with IBC Transfer transactions, IBC RecvPacket and IBC Acknowledgement transactions are established and approved. To prevent spam on the mainnet, set a minimum gas price and accept only transactions within that range [20]. This experiment employs a basic transaction fee of 260 UATOM to allow transactions to proceed without being filtered or blocked. The RPC (Remote Procedure Call) [21] command’ gaiad tx ibc-transfer transfer [src-port] [src-channel] [receiver] [amount] [flags] is used to build inter-blockchain communication transactions, specifically IBC Tx Generation Controller transactions. The transaction creation command of the Cosmos Hub is written in Go [22]. The transaction can be broadcast immediately by entering the critical password and selecting ‘--yes ’ in the flag field. The IBC Tx Generation Controller saves the transaction data output from the Cosmos Hub client as IBC Tx Generation data, along with the time after entering the critical password.

This controlled transaction creation technique enables the systematic generation and tracking of inter-blockchain communication transactions for extra analysis and evaluation.

3.2.2. Data Collection Process

The Tx Data Collector, linked to the Cosmos Hub and Osmosis clients, seeks and obtains the most recent blockchain data from the associated nodes via a synchronization technique during the data collection. The block data contains information about the inter-blockchain communication transactions generated by the transaction generation controller, such as their commitment status and timestamp. The Cosmos Hub client functions in the same way as other normal network nodes. The existing Osmosis client’s RPC receiving port waits for incoming requests on the same TCP port 26657 as the Cosmos Hub. The Osmosis client on the Measurement Node utilizes TCP port 26757 to avoid port duplication within the same node.

The Tx Data Collector, linked to the Cosmos Hub and Osmosis clients, queries transaction data via the RPC commands given by each client, namely ‘gaiad’ and ‘osmosisd’. The Gaiad command ‘gaiad query txs --height [height] --events’ {eventType}.{eventAttribute}={value}’ [flag]’ [17] can be used to obtain transactions included in a block. Osmosis uses the same command structure as Gaiad, but substitutes ‘gaiad’ with ‘osmosisd’ and adds the ‘--node= “tcp://127.0.0.1:26757”’ parameter to specify the receiving RPC port number for querying transactions [18]. The inter-blockchain communication (IBC) transaction created by the IBC Tx Generation Controller is the transaction data used in the measurement and analysis. It queries the IBC Tx Generation Controller’s transactions by giving the block height at the beginning of the transaction generation process and adding the transaction event types maintained by each client.

Table 2. Cosmos IBC transactions.

Types	Key	Value
message	action	/ibc.applications.transfer.v1.MsgTransfer
		/ibc.core.channel.v1.MsgRecvPacket
		/ibc.core.channel.v1.MsgAcknowledgement
	sender	cosmos1q5prlm6rjru5cpxajmugts6gyrhnd5luzshg4w
fungible_token_packet	receiver	osmo1exmtwm3vtj6sk2plmhg4xjhjjd8at2scdg6tww

shows the event types that were employed in data gathering.

Figure 7 depicts the process of gathering committed transaction data from Cosmos Hub and Osmosis clients using RPC instructions. Only one-way transfers of fungible tokens from the Cosmos Hub to Osmosis are undertaken in this study. As a result, the sorts of transactions to be collected from each client are predetermined. The inter-blockchain communication transactions generated and committed by the IBC Tx Generation Controller are saved as IBC Transfer Tx, IBC Recv Tx, and IBC Ack Tx data throughout the data collection process.

3.3. Message Tracing Model

3.3.1. Valid Transaction Filtering

IBC Recv Tx and IBC Ack Tx data are entered into the valid transaction filtering process generating IBC Recv Tx and IBC Ack Tx data—multiple relayers relay transactions between the Cosmos Hub and the Osmosis Network. The Relayer searches the sending chain’s most recent ledger state for inter-blockchain communication transactions, then broadcasts them to the receiving chain by appending an IBC UpdateClient transaction for proof of state. Signers certify the up-to-date status of the transmission chain in an IBC UpdateClient transaction [20]. Entering the wallet address of the Relayer who will relay the transaction in the signer box and adding an IBC UpdateClient transaction turns the transaction for one fungible token transfer into a transaction with a new hash. In the transaction of the transfer of the same fungible token, an inter-blockchain communication transaction is established for each Relayer, as shown in Figure 8. The receiving blockchain contains all created transactions.

Each Relayer generates an IBC transaction for every fungible token transfer, resulting in several transactions involving the same token in the recipient blockchain. The receiving chain combines these transactions into a single block, generating an IBC Recv Tx for each receiving IBC Transfer Tx. The sender chain is notified that the fungible token transfer successfully delivered an IBC Ack Tx. The first transaction that reaches the Proposer’s mempool is validated by the inter-chain transactions in the Cosmos Hub and Osmosis blocks. A token voucher is deposited to the recipient’s wallet, and the Relayer who originated and disseminated the transaction receives a reward from the transaction charge [20,23]. In addition, the permitted IBC Recv-Packet transaction is constructed and sent to the sender blockchain.

Transactions with a positive fee field (Fee > 0) are separated from the IBC Recv Tx and IBC Ack Tx data and preserved as legitimate IBC Recv Tx and Valid IBC Ack Tx data. These transactions were completed successfully at a low transaction cost. As a result, they are considered valid. The filtering technique is depicted in Figure 9. Because IBC Transfer transactions propagate and reach a consensus within the Cosmos Hub without the assistance of relayers, there are no duplicate transactions in the IBC Transfer Tx data.

3.3.2. Sequence Tracing

Sequence tracing tracks transaction data to aggregate the timestamp values for each inter-blockchain communication transaction. The information is recorded as IBC Msg Relay Time. Several transaction datasets, including IBC Tx Generation, IBC Transfer Tx, Valid IBC Recv Tx, and Valid IBC Ack Tx, share the precise Sequence identification [10]. The Txhash from the IBC Tx Generation identifies a specific fungible token transfer. It is a 1:1 match with the Txhash of the IBC Transfer Tx. Every IBC Tx Generation includes a timestamp indicating the start of inter-blockchain communication transactions.

In contrast, the IBC Transfer Tx, Valid IBC Recv Tx, and Valid IBC Ack Tx sequences are matched based on the Source_channel and Destination_channel. The timestamp of the block containing these transactions is included. In the IBC Msg Relay Time, a sequence trace on the transaction data stores the timestamp value for each fungible token transmission. This trace ensures that the timestamp data has been correctly aggregated. The sequence tracing process used to obtain and preserve timestamp values in the IBC Msg Relay Time is displayed in Figure 10.

3.3.3. Calculating Message Relay Time

In this study, the IBC Msg Relay Time refers to the period between the propagation of an IBC Transfer transaction and the commit and inclusion of the associated IBC Acknowledgement transaction. It measures the time needed to validate and complete a transaction after commencing a fungible token transfer. Figure 11 depicts the IBC Msg Relay Time as three segments: G to T, T to R, and R to A.

The G to T interval represents the time an IBC Transfer transaction needs to be propagated and committed, as shown in Figure 12. The T to R interval is the time between the IBC Transfer transaction’s commitment and the corresponding IBC RecvPacket transaction. The R to A interval is the time between the commitment of the IBC RecvPacket transaction and the commitment of the IBC Acknowledgement transaction.

The IBC Tx Generation Controller records the transaction propagation time using the now() method from the Python DATETIME module. Block generation duration is expressed in Coordinated Universal Time (UTC) seconds. The generation_time is measured in milliseconds in Korean Standard Time (KST). Because KST is 9 h ahead of UTC, we subtracted 9 h from the observed generation_time to account for the time difference. In the IBC Msg Relay Time, the block creation times that contain the associated transactions are Transfer_time, Recv_time, and Ack_time.

The Tendermint consensus engine is used by Cosmos Hub and Osmosis [20,23,24]. The block creation time in Tendermint is predictable and provides Byzantine fault-tolerant times. The Pre-commit message [24] determines the block creation time, which has time monotonicity. The property of time monotonicity states that the block generation time increases monotonically as the block height increases. Given block heights H and H + 1, the generation time of H + 1 cannot be sooner than the generation time of H (H.Time < H + 1.Time). The block creation time is the median of the time values that list the time of the Precommit message submitted by the validator at the final stage of the block consensus process as the number of times proportional to the voting power. For example, if three validators each have 23 votes, ten votes, and ten votes, they vote by entering the time of the Precommit message as 98, 100, and 500 in turn. At this time, the block formation time is the median of 98 among the values derived by the number of times proportional to voting power. The sum of one’s stake and delegated tokens equals one’s voting power [23,25]. Voting power weights votes, and the greater it is, the more frequently it can act as a block proposer [26]. Tendermint’s method of determining block creation time is that the median is always between the values supplied by the proper validators if the correct validators have at least 2f + 1 (f = the number of erroneous validators) voting power. Because there was no change in the overall number of validators or the ranking of voting power during the experiment period, Cosmos Hub and Osmosis blockchain are presumed to retain a constant time.

4. IBC Time Analysis Method

4.1. Kernel Density Estimation

Kernel density estimation (KDE) is a statistical method that uses a small sample of data to estimate a population’s underlying probability density function. It is a non-parametric technique in which the data is not assumed to have a specific distributional form. By applying a kernel function to each data point, KDE generates a smooth, bell-shaped curve (typically a Gaussian or normal distribution). The bandwidth parameter governs the smoothness of the estimate.

The seaborn.kdeplot() [27] method in Python can be used to generate kernel density estimation charts. From the observed data, this function builds a histogram, normalizes it to form a probability density function, and applies the kernel function ($K_h$) to each data point. Equation (1) gives the equation for estimating kernel density:

$$\widehat{f_h}\left(x\right)=\frac{1}{n}\sum _{i=1}^n{K}_h\left(x-x_i\right)=\frac{1}{nh}\sum _{i=1}^{n}k(\frac{x-x_i}{h})$$

(1)

$n$ is the total number of observations, $x_1,x_2,\dots ,x_n$ are the observed sample data, $K_h$ is the kernel function, $x$ is the variable of interest, and $h$ is the bandwidth parameter.

Choosing the proper kernel function and accurately choosing the bandwidth value is critical for practical kernel density estimation. The kernel function is used to determine the shape of the density estimate. In contrast, the smoothness of the estimate is controlled by the bandwidth parameter. Although a larger bandwidth offers a smoother estimate, it may over smooth the data. A lower bandwidth, on the other hand, produces a more detailed estimate, but it may bring noise into the estimate.

4.2. Lognormal Distribution

A continuous probability distribution called the lognormal distribution is widely used to explain positive and skewed data. It describes a random variable with a logarithmic distribution. The lognormal distribution is frequently used to model data with positive skewness, such as financial returns or natural phenomenon sizes. It offers a method for transforming data into a normal distribution for analysis. Equation (2) gives the probability density function (PDF) of the lognormal distribution:

$$\mathrm{N}\left(\mathrm{x}; \mathsf{\mu },{\mathsf{\sigma }}^2\right)=\frac{1}{\sqrt{2\mathsf{\pi }}\mathsf{\sigma }\mathrm{x}}\exp \left(-\frac{(\ln \mathrm{x}-\mathsf{\mu }{)}^2}{2{\mathsf{\sigma }}^2}\right)$$

(2)

where $x$ is a variable, $\mathsf{\mu }$ is the logarithmic mean, $\mathsf{\sigma }$ is the logarithmic standard deviation, ln is the natural logarithm, and exp is the exponential function.

A lognormal process is statistically defined as the multiplicative product of several positive independent random variables. The lognormal distribution changes into a normal distribution when the natural logarithm of the data collection is used. Because the logarithm is undefined for non-positive numbers, the lognormal distribution is only appropriate when the amount of interest is positive. The lognormal distribution has a concave contour on the left side.

4.3. Correlation Coefficient

The correlation coefficient, a statistical metric, quantifies the strength and direction of a two-variable linear relationship. It returns a numerical value indicating how closely the variables’ data points align with a straight line. The correlation coefficient is calculated using the variable means and total squared deviations. It goes from $-1.00$ to $+1.00$, with the sign indicating the direction of the link and the absolute value indicating the intensity of the relationship. Positive correlations suggest that changes in one variable cause changes in the other, whereas negative correlations indicate an opposite link.

Equation (3) gives the equation for obtaining the correlation coefficient between two variables, $\mathrm{x}$ and $\mathrm{y}$:

$$\mathrm{r}=\frac{\sum \left[\right({\mathrm{x}}_{\mathrm{i}}-\overline{\mathrm{x}}\left)\right({\mathrm{y}}_{\mathrm{i}}-\overline{\mathrm{y}}\left)\right]}{\sqrt{\sum ({\mathrm{x}}_{\mathrm{i}}-\overline{\mathrm{x}}{)}^2\ast \sum ({\mathrm{y}}_{\mathrm{i}}-\overline{\mathrm{y}}{)}^2}}$$

(3)

If ${\mathrm{x}}_{\mathrm{i}}$ and ${\mathrm{y}}_{\mathrm{i}}$ are individual data points of $x$ and $y$, $\overline{x}$ and $\overline{y}$ are their respective means. Total squared deviations $\sum ({\mathrm{x}}_{\mathrm{i}}-\overline{\mathrm{x}}{)}^2$ are calculated by comparing the distances between each data point and the variable’s mean.

Correlation coefficients between $\pm 0.4$ and $\pm 0.7$ are considered moderately correlated. It is important to note that correlation coefficients only measure linear links and may not capture all forms of relationships or demonstrate causality between variables. The correlation coefficient is widely used in many domains, including economics, social sciences, and finance, to investigate and comprehend the links between diverse variables and their impact on one another.

5. Results and Analysis

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 $4114\times 2$ 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 $\times 1.3$ 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 $\times 1.3$ 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. IBC Time Statistics Summarized by Message Relay Time Intervals.

Message Relay Time Interval	Min	Max	Mean	Median	Var	Std
G to T time	0.0	79.308	19.623	16.732	123.483	11.112
T to R time	3.0	72.0	13.515	13.0	16.449	4.055
R to A time	5.0	94.0	22.310	18.0	172.626	13.138

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. Analysis to Determine Distribution of IBC Time.

	Statistics	p-Value
Kolmogorov-Smirov	0.0194284334	0.8391204478
Shapiro–Wilk	0.9971379041	0.0730665996

, 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. Message Relay Time Range by Percentage.

Percentage (%)	IBC Message Relay Time Range
68.3	(28.59904, 62.768295)
95.4	(19.304439, 92.989672)
99.7	(13.030552, 137.761891)

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. Message Relay Time Range by Percentage.

Message Relay Time Interval	IBC Message Relay Time Range by Percentage
G to T time	0.602792
T to R time	0.214533
R to A time	0.731259

, 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.

6. Discussion

6.1. Performance Analysis of Cosmos Inter-Blockchain Communication

This research thoroughly examines the performance of Cosmos’ inter-blockchain communication protocol, particularly emphasizing message delivery times within the Cosmos ecosystem [28,29]. We have obtained valuable insights into the behavior and characteristics of message delivery times through data collection and statistical inference.

Our findings show that the delivery time of inter-blockchain messages in Cosmos follows a lognormal distribution, ranging from 28.176 to 138.662 s. It is worth noting that the entire delivery time on Cosmos is roughly 2.8 times that of the Cosmos Hub blockchain; this suggests that elements within the ecosystem contribute to message delivery delays.

We have found that vital time intervals, such as G to T (Generation to Transmission) and R to A (Relay to Acknowledgement), considerably impact message transmission efficiency. Understanding and optimizing these intervals can enhance inter-blockchain communication effectiveness and reliability.

Our research also identifies areas for development within the Cosmos Hub ecosystem, which may help to reduce message delivery delays. Future studies will benefit from analyzing the causes of these delays and devising techniques to reduce transfer times in Cosmos.

The findings of this study have significance for improving inter-blockchain protocols, allowing for smooth communication between blockchains. We can improve the interoperability and performance of blockchain networks by resolving the highlighted concerns and applying the suggested adjustments. As a result, decentralized systems and applications will be more widely adopted and advanced.

This research gives valuable information about the efficiency of inter-blockchain message delivery inside the Cosmos ecosystem. This paper’s statistical analysis and results serve as a platform for future study and optimization efforts in blockchain interoperability. We can improve the effectiveness and dependability of inter-blockchain communication by tackling the stated obstacles and exploiting the information gained, ultimately developing decentralized systems and applications.

6.2. Strategies for Optimizing G to T and R to A Intervals

Optimizing the G to T (Generation to Transmission) and R to A (Relay to Acknowledgment) periods in inter-chain communication is essential to increase the overall effectiveness and dependability of blockchain networks, such as Cosmos.

To enhance G to T intervals, consider using parallel processing strategies that enable the Cosmos Hub to execute transactions simultaneously. Critical data transfers can be sped up by classifying transactions according to priority or urgency. To avoid bottlenecks, load-balancing algorithms assist in distributing transaction processing responsibilities equally across nodes. Additionally, investigating more effective consensus methods might hasten transaction validation without sacrificing security.

Focus on building lightweight acknowledgment protocols that utilize little processing resources to optimize R to A intervals. Message acknowledgment is ensured by network redundancy even when a significant route faces congestion or delays. Predictive analytics can estimate network congestion trends ahead of time and modify acknowledgment intervals accordingly. Using dynamic scaling to allocate resources based on demand, allows quick acknowledgments during peak activity. Intelligent caching strategies keep frequently accessed acknowledgment data closer to nodes, lowering retrieval time. Finally, real-time monitoring and feedback systems give information about acknowledgment timings, enabling automated network adjustments to optimize R to A intervals based on actual network conditions. Continuous monitoring and iterative enhancements are required to ensure efficient inter-chain connectivity within the Cosmos ecosystem while adhering to specific use cases and the expanding blockchain.

7. Conclusions

This study thoroughly examines Cosmos’ inter-blockchain message transfer performance and communication protocol. The findings shed light on the behavior and characteristics of message delivery times in the Cosmos ecosystem. According to the data, IBC message relay time followed a lognormal distribution, with an average transfer time of 55.448 s. The R to A time section substantially impacted overall message transmission efficiency, resulting in delays in the IBC message relay process. Furthermore, the study emphasized the importance of improving inter-blockchain protocols to enhance communication and reduce transfer times. Future studies should look at the fundamental reasons for message relay delays and provide solutions to improve the Cosmos protocol between existing blockchains. By tackling these issues, we may improve blockchain network performance and interoperability, boosting the potential uses of decentralized systems and applications.