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

Slashing: special kind of slashing-by-transaction for infractions older than an unbonding period #1378

Closed
cwgoes opened this issue Jun 26, 2018 · 5 comments

Comments

@cwgoes
Copy link
Contributor

cwgoes commented Jun 26, 2018

Our slashing model is built on "follow-the-stake": we want to slash stake which contributed to an infraction which is discovered later (after the state has changed), so we need the ability to recover the state of the stake (which accounts contributed how much by delegation or self-bonding) at the time of the infraction. Presently, Gaia only tracks enough information (redelegations / unbonding delegations) to recover the state of a validator's stake for infractions committed an unbonding period or less prior to discovery (an archive node can elect to track all past states, but we probably don't want to require that).

If we want to slash bonded validators for infractions committed longer than an unbonding period in the past - #1022, to encourage key rotation - we could create a special slashing transaction which proved a double-signature at the time of infraction (exposing a way to load previous headers in the handler and charging gas on the transaction to prevent spam), or just have the slashing BeginBlock function accept evidence older than unbonding period (depending on whether we want to support slashing evidence beyond Tendermint's maximum evidence age).

The tricky part is following all the stake. Unbonded or redelegated stake is no longer eligible to be slashed after an unbonding period, but we still need to calculate somehow the changes to the stake since the infraction, so we can avoid slashing stake which has bonded to the validator since the infraction. In principle, the transaction itself could include proofs of stake changes, although this seems complex to implement.

Another option is simply to slash stake which has bonded since the infraction even though it didn't contribute, which removes all this complex calculation.

@ebuchman Is this summary accurate / am I missing an obvious solution here?

@rigelrozanski
Copy link
Contributor

rigelrozanski commented Jun 29, 2018

  • Tokens that are no longer bonded or unbonding(/redelegating) from the a misbehaving validator can simply not incur slashes for earlier (>unbonding-period) behaviour of a previous validator.
  • The premise of cosmos is that is does not meddle with stake which has been unbonded from the violating validator.
  • the protocol could however choose to arbitrarily slash-by-association additional stake which did not actually participate in bad behaviour but is bonded to the validator which did - I don't see a problem with this so long as the circumstances are explicitly communicated.

@cwgoes
Copy link
Contributor Author

cwgoes commented Aug 17, 2018

Tabled to post-launch in favor of #2081.

@jackzampolin
Copy link
Member

Is this still something we want to implement?

@cwgoes
Copy link
Contributor Author

cwgoes commented Jul 4, 2019

Is this still something we want to implement?

I think this needs to be part of a broader discussion of light client security & efficiency.

That's where decisions here are most relevant.

@jackzampolin
Copy link
Member

Going to link this to the applicable issue on gaia and close it here.

chillyvee pushed a commit to chillyvee/cosmos-sdk that referenced this issue Mar 1, 2024
* add release to workflow

* change github env for build binary

* add changelog and build_report to release note

* Update main.go

* refactor: file path

* add release note title

* Update .github/workflows/release.yml

* bump checkout to v3

Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants