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

New gRPC endpoint to query for connection GenesisState #1628

Closed
3 tasks
adizere opened this issue Jun 30, 2022 · 4 comments
Closed
3 tasks

New gRPC endpoint to query for connection GenesisState #1628

adizere opened this issue Jun 30, 2022 · 4 comments

Comments

@adizere
Copy link

adizere commented Jun 30, 2022

Summary

Is there a way to query for GenesisState of connection?

In the relayer implementation, we need to programatically obtain the Params in there.

Problem Definition

Why do we need this feature?

We need the Params specifically for max_expected_time_per_block which is essential in the implementation of connection (block) delay

Proposal


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@colin-axner
Copy link
Contributor

I believe there is a way. If I understand correctly, the information you want is simply the current value of the max_expected_time_per_block, not necessarily the genesis value (since it is a param, gov can change it over time). If so, params has it's own grpc. I believe the subspace is "ibc" (I may be mistaken), and the key is this

The SDK has plans to remove x/params in the future, so future versions may require IBC to manage our own parameters, in which case we will expose a similar grpc for retrieving this value

@colin-axner
Copy link
Contributor

I opened #2069. We will try to integrate this gRPC early so that when x/params are deprecated, most chains should support the params gRPC associated with 03-connection

@adizere
Copy link
Author

adizere commented Sep 21, 2022

Thanks Colin & Carlos for shepherding this request.

I think the present issue #1628 can be closed in favor of #2069. The latter issue should be sufficient for operator needs, in particular for informalsystems/hermes#2037 and implementation of connection delay.

@crodriguezvega
Copy link
Contributor

Thanks, @adizere!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants