R4R: Implement slashing period

[cwgoes]

Implements #2001.
Depends on #2120.
Replaces #2121.
Closes #1990.

• Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
• Wrote tests
• Updated relevant documentation (docs/)
• Added entries in PENDING.md with issue #
• rereviewed Files changed in the github PR explorer

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #2122 into develop will increase coverage by 0.09%.
The diff coverage is 77.57%.

@@            Coverage Diff             @@
##           develop   #2122      +/-   ##
==========================================
+ Coverage    63.51%   63.6%   +0.09%     
==========================================
  Files          136     139       +3     
  Lines         8370    8454      +84     
==========================================
+ Hits          5316    5377      +61     
- Misses        2692    2713      +21     
- Partials       362     364       +2

[cwgoes]

Thinking about the best way to implement the slashing period hooks - do we have way for two keepers to mutually reference each other? Ideally the slashing period logic would live in the slashing module, and the staking module would call into it as described in the spec.

Certainly we can do this with common types defined in types/ and something like:

a := newStakingKeeper(...)
b := newSlashingKeeper(a, ....)
a.setSlashingKeeper(b)

but that's a bit ugly, and I wonder if we have any concerns with this pattern.

cc @rigelrozanski

[cwgoes]

Also, I think this is probably about the right time to split slashing into subpackages as per #1779 - but I'm going to do it in a separate PR, after the functionality changes, to make review easier.

[rigelrozanski]

I think the code pattern you've described makes sense - especially so if a takes a an interface version of b

Certainly we can do this with common types defined in types/ and something like

ideally the staking module actually defines what interface it needs for b even though the core implementation happens in a different module (staking module should probably implement a dummy slashing keeper for staking tests in that situation).

Yeah splitting up as a second PR makes sense

[cwgoes]

This is not being written for Tendermint NextValSet, that will happen in a separate PR. Note that slashing period heights will need to be offset.

[rigelrozanski]

hello!

[melekes]

dummy question: is it only possible to have just one slashing period per keeper?

[cwgoes]

No, it's possible to have one per validator per start height - the key is partially read from the ValidatorSlashingPeriod struct.

[melekes]

Ok, thanks. It's just the method name IMHO implies that there's only one period. addValidatorSlashingPeriod would make more sense

[cwgoes]

Good point, changed to addOrUpdateValidatorSlashingPeriod

[rigelrozanski]

@cwgoes responded to all your comments from my review above ^

I've marked everything which I'm satisfied with as "resolved" (new github feature) everything that is not marked as resolved (including outdated comments) is worth a further comment

[cwgoes]

Updated for #2040 which is an unfortunate confusion of concerns but there's no way around it.

[rigelrozanski]

gah! attack of the untested merge! This merge broke develop working on a fix right now. It looks like it didn't have the most recent recent develop merged into it :(