V018 impacted delegator unable to redelegate

[hard-nett]

tx link: https://www.mintscan.io/bitsong/tx/B0F64649FC4C287EEE0AB0F1F9CC57F5B222095BB219A6AD42EF95E0724FAC48?height=20288910

Context

When redelegating, the staking module triggers the BeforeDelegationSharesModified hook for the distribution module, in order to claim any pending rewards the delegation is entitled to.

Due to the nature of the new staking keeper was being created with go-bitsong version <= v0.18.0 & >=v0.20.0, none of the staking hooks were correctly registered to the keepers implementing these hooks (slashing & distribution) involving any delegation from validators that have committed slashing events since upgrading to v18.

Root Of Issue

When a copy of the stakingKeeper instance was being made it was dereferenced with *stakingkeeper.NewKeeper. Then, the hooks were being set on this copy, but the original instance was not being modified. This means none of the staking keeper hooks were successfully applied to the app-state when called.

What is impacted

Any hook that the staking keeper triggers does not get called, leading data in the distribution and slashing state being stale. The following digram maps out each hook the staking keeper calls

Resolution Steps

1. Remove dereference operator * so staking hooks are being set on the correct instance.

This commit has been included in #252 .

2. SDK Patch

A fork of the Cosmos-SDK used will replace the original one used in the go-bitsong application that includes a bypass to the sanity check in x/distr when claiming rewards. Specifically , if the voting power calculated for a delegation from the data in the distribution module is greater than the voting power based on data from the staking keeper is differed, so that the calculated voting power returned will be set based on the data stored in the staking keeper. This is possible as the staking KVStore was not impacted at all by the incorrect staking hooks registration, just the slashing and distribution.

fork link: https://github.com/bitsongofficial/cosmos-sdk/releases/tag/v0.47.15-bitsong

3. Patch KVStore with correct historical data

The third steps goal is to deterministically obtain & set any data that did not get added or removed in both the x/slashing and x/distribution modules KVStores. This will fix any mistakes in these modules store used by bitsong, and will allow for historical queries of this data's contents. Since an emergency halt and upgrade was applied, we know there is an exact number of blocks bitsong was impacted by this bug, therefore allowing us to isolate what messages did not successfully update either the x/distribution store, or x/slashing store.

x/distribution

1. First, any slashing event by a validator that occurred from v018 to the v0.20.4 coordinated upgrade, needs to be added into the store via SetValidatorSlashEvent. This will resolve any data missing to be added or removed due to the BeforeValidatorSlash event.
   The ValidatorSlashEventPrefix byes are 0x08, and the key uses the validator the height and its rewards period.
   key format function: https://github.com/cosmos/cosmos-sdk/blob/f008f84e3cd39fbe5b0894ed43c937e6582fd497/x/distribution/types/keys.go#L210

These stores are deleted on the AfterValidatorRemovedHook when a validator is deleted.

2. Second, any validator create from v018 to the v0.20.4 coordinated upgrade needs to be registered.There were not any so we can disregard this step.

3. Third, any validator that was removed needs to have the AfterValidatorRemoved hooks called again

4. Next, we need to verify what to do in regards to the delegation in the distribution store, specifically made or modified to validators that did not have their slash event added to the store. Heres what we know:

• no delegations were modified to impacted validators, until v20 upgrade patch applied.
• 0 power delegations to validators jailed exists
• all rewards redeemed by delegators have been accurately calculated by the tokens shares of their delegation, which is data properly stored in the x/slashing keeper.

Since calculating pending rewards for a delegation uses the validators latest period, which is updated whenever an action that calls the staking hooks (claim, redelegate, delegate), and this occurred first for each impacted delegator during v020 upgrade when rewards were manually claimed, we most likely can avoid manually updating these stores with missing data.

The only data that needs to be updated in the x/distribution module is removing any delegations with 0 voting power and any other store context related to it.

x/slashing

1. First, any new validator created needs its pubkey mapping added. There were not any during this period so we can disregard this step.
2. Second, and validator removed needs the pubkey mapping removed. Validators are removed when they have all delegations removed, their total tokens are 0 and they are unbonded.