cosmos/ibc

ICS4: Eureka Timeout Representation

Opened this issue · 1 comments

AdityaSripal commented

From our experience with IBC v1, the semantics around timeout height are very confusing to users and implementors and timeout timestamp is preferred in almost all cases.

However, timeout timestamp requires a chain to have BFT time (either in protocol or available as a trusted oracle within the state machine).

Thus, there are a few open questions:

  1. Do we want to enforce BFT time and only rely on timeout timestamps
  2. What should the value of these timeout timestamps be? In Cosmos SDK, the time is represented in nanoseconds, in Ethereum block time is in seconds. What level of granularity is most useful, and should we simply stay on the same time unit as v1 so as not to be disruptive?
  3. How should we represent the timeout both in the packet and within the packet commitment structure. Should we assume uint64 if we stay with timeout timestamp only or should we make the representation more malleable to account for different platforms