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

punishment module #246

Closed
rigelrozanski opened this issue Sep 2, 2017 · 13 comments
Closed

punishment module #246

rigelrozanski opened this issue Sep 2, 2017 · 13 comments

Comments

@rigelrozanski
Copy link
Contributor

I'm thinking that all the slashing and associated proofs, as well as the logic associated with unbonding a validator with poor availability could maybe fit neatly into a SDK module? Am I out to lunch? The unbonding validator functionality would need to interface with the staking module to actually perform the unbond. Thoughts?

@adrianbrink
Copy link
Contributor

We need to forcibly unbond validators that are unavailable.

I think everything that involves changing the voting power of a validator, such as getting slashed or going offline, should live within a single module. The latter just doesn't cause a reduction in the stake.

@rigelrozanski
Copy link
Contributor Author

rigelrozanski commented Sep 2, 2017

From Slack: adrian [3:08 PM]
What happens if a validator drops offline? Do we currently handle this?

rige [3:09 PM]
This will need to be a part of the “slashing” module or something to that effect
The consensus should still continue if less than 1/3 of validators are offline
as I understand it
But we still need a way of punishing validators if they have low availability I think
But yeah not a part of the staking module right now. Currently validators are rewarded equally for being around, not dependant on being the “leader” validator for a block or anything
But yeah I think this needs to be a part of post-process evaluation of validator performance which is coupled with slashing. Should probably be the same place where we can publish proofs and slash validators for double signing etc.

adrian
cool. I'm just reading the Jepsen report and started wondering about the offline case. I don't think the need to get slashed necessarily, but they need to get removed from the validator set.

rige [3:15 PM]
Oh good point… they could be disqualified from the validator set… I still think this should be a part of a separate module, but yes should interact with the staking module to basically forcibly “unbond” a bad validator. cool

@rigelrozanski
Copy link
Contributor Author

hmm.. Also a good point that slashing also involves changing the validator set because less bonded tokens (and some punishments should also including unbond the tokens if clearly malicious)... I'm still leaning to seperate module interacting with the staking module though... we have these interact easily, and staking should really be reserved for the staking side of things, folks may want to implement customized punishment rules for their blockchains

@ethanfrey
Copy link
Contributor

  1. I love the name "punishment module"
  2. I think it makes sense to separate this module as much as possible and then trigger stake slashing via IPC
  3. Does this module also need to track the amount of stake? Or just say - slash 50% on validator XYZ? The first would be a bit tricky and then need to be integrated in with staking. The second would work well independently.

@rigelrozanski
Copy link
Contributor Author

  1. 👍
  2. 👍
  3. I think typically slashes have been discussed as percentages, but I think we could always provide an option to the staking module to slash by ("slash whichever is greatest, either 5% or 1000 atoms") I cannot see why the punishment module would require comprehensive knowledge of the validator balances

@rigelrozanski
Copy link
Contributor Author

Bucky seems to think that the punishment module "punmod" may actually want access to the bond amounts. May have to make this queryable..

@sunnya97
Copy link
Member

sunnya97 commented Sep 6, 2017

Somewhat related, but shouldn't "unavailable" validators cause the rewards of all validators to be decreased, not just the "unavailable" one?

Are rewards in the staking module?

@rigelrozanski
Copy link
Contributor Author

@sunnya97 yes rewards are in the staking module... This is an interesting question as to whether the group of all validators should be punished for loss in availability in a single (or a threshold) of validators. I think CASPER may be exploring this idea, you'll need to hit up @ebuchman on that question. Ultimately I'd like to see an incentive evaluation on this idea to arrive at a logical conclusion as to why or why we should implement collective punishment

@ebuchman
Copy link
Member

ebuchman commented Sep 6, 2017

At the very least, the design of the SDK should enable it easily

@silasdavis
Copy link

silasdavis commented Oct 26, 2017

Will Tendermint provide invalidator behaviour information over ABCI so that apps can implement punishment? How will his work, will be we be passed additional information on BeginBlock?

@ebuchman
Copy link
Member

Yes, tendermint/tendermint#569

@ebuchman
Copy link
Member

stale. this is part of staking module

@rigelrozanski
Copy link
Contributor Author

liveliness is part of the staking module but what about punishment for other behaviours? Do we have an outline of all punishable behaviour? @sunnya97 @ebuchman

catShaark referenced this issue in notional-labs/cosmos-sdk Jun 11, 2022
sosedoff referenced this issue in figment-networks/cosmos-sdk Jun 12, 2022
(cherry picked from commit f69c198)

Co-authored-by: Roman <[email protected]>
roysc pushed a commit to vulcanize/cosmos-sdk that referenced this issue Jul 16, 2022
(cherry picked from commit f69c198)

Co-authored-by: Roman <[email protected]>
roysc added a commit to vulcanize/cosmos-sdk that referenced this issue Jul 21, 2022
(cherry picked from commit f69c198)

Co-authored-by: Roman <[email protected]>
rootulp referenced this issue in rootulp/cosmos-sdk Oct 21, 2022
…ial-probably

chore!: Upgrade QGB branch to v0.46.0
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

6 participants