# Inter-Blockchain Communication Message Relay Time Measurement and Analysis in Cosmos +
## 3 Data Collection and Methodology
### Message Tracing Model
#### 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 Ac  
Figure 11: Intervals of message delivery.  
Figure 10: The tracing process of Transaction data.  
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.