Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICS4: Eureka Timeout Representation #1146

Open
AdityaSripal opened this issue Sep 2, 2024 · 1 comment
Open

ICS4: Eureka Timeout Representation #1146

AdityaSripal opened this issue Sep 2, 2024 · 1 comment
Labels

Comments

@AdityaSripal
Copy link
Member

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
@AdityaSripal
Copy link
Member Author

cc: @colin-axner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

1 participant