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

Query Slashing Parameters #2399

Closed
1 of 4 tasks
fedekunze opened this issue Sep 25, 2018 · 11 comments · Fixed by #3117
Closed
1 of 4 tasks

Query Slashing Parameters #2399

fedekunze opened this issue Sep 25, 2018 · 11 comments · Fixed by #3117
Assignees

Comments

@fedekunze
Copy link
Collaborator

fedekunze commented Sep 25, 2018

Summary

Expose slashing params via Gaia-lite and CLI

Problem Definition

On voyager we were trying to track validator uptime (in this case defined as the amount of blocks they signed), which is possible with using the signing_info, but the problem is that we rely on the defaultSignedBlocksWindow to calculate the uptime on the rolling window. That means if the parameter is changed through governance clients won't be able to get the new parameter (besides of hardcoding the value).

Proposal

@alexanderbez : I think we should just expose everything that has a getter in slashing/params.go

Create a GET /slashing/parameters endpoint and CLI cmd to expose the params


For Admin Use

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

ValarDragon commented Sep 25, 2018

I think this should use the paramstore once thats merged, and should be generalizable. More along the lines of either: params/param_name or params/slashing/sub_param_name

@ValarDragon ValarDragon added the S:blocked Status: Blocked label Sep 25, 2018
@alexanderbez
Copy link
Contributor

alexanderbez commented Sep 25, 2018

For sure! We can still have the endpoint and update later.

@jackzampolin
Copy link
Member

This proposal is accepted! Is there anyone working on implementation here?

@ValarDragon
Copy link
Contributor

The paramstore isn't merged yet.

@alexanderbez
Copy link
Contributor

And params/slashing/ should return all of them.

@jackzampolin
Copy link
Member

I think we should serve the params from the routes of the module that instantiates them so that would be /slashing/params

@ValarDragon
Copy link
Contributor

Just want to note that we can still do that in a standardized way from params.

Personally I like params coming first, but you probably have a better understanding of how clear it would be to the average user so I'm fine with slashing/params

@jackzampolin jackzampolin changed the title Expose slashing params to clients Query Slashing Parameters Oct 12, 2018
@fedekunze
Copy link
Collaborator Author

is this still blocked ?

@fedekunze fedekunze removed the S:blocked Status: Blocked label Oct 17, 2018
@fedekunze
Copy link
Collaborator Author

@ValarDragon @jackzampolin do you guys know if the param store got merged so we can move forward with the implementation of this issue?

@alexanderbez
Copy link
Contributor

Param store is merged afaik.

@jackzampolin
Copy link
Member

That would unblock this...

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

Successfully merging a pull request may close this issue.

4 participants