Problem: Missing validator delegation in validator projection

[calvinaco]

No description provided.

[ysong42]

After reading CosmosSDK document and diving into their codebase, I had some findings.

Here are my notes:
https://github.com/crypto-com/chain-indexing/wiki/Staking-Notes
https://github.com/crypto-com/chain-indexing/wiki/Slashing-Notes

[ysong42]

Three things to follow up:

1. How to get the delegations amount on each validator?
2. How to add new events on CosmosSDK?
3. Arrange a follow-up discussion meeting on this Wednesday or Thursday.

[ysong42]

For getting delegations list on each validator, I could think of two ways to do this:

• Add new events on CosmosSDK side, whenever a delegation changes (Delegation.Shares.Sub or Delegation.Shares.Add).
• Not adding new events on CosmosSDK side. Keep track of Validator, Delegation, Redelegation entries on our own indexing server.

[ysong42]

One serious problem for adding new events on CosmosSDK is that, even if these events are added to a new version of CosmosSDK, the old blocks won't emit the newly added events.

As the old blocks need to be synced with the old binaries, which are using old version CosmosSDK.

[ysong42]

cosmos/cosmos-sdk#10799

According to the discussion in the above thread. We will need to setup multiple archive nodes that stop at different upgrade height, using different versions of binaries.

So that we could query historical states from this set of nodes.

This has not been tested on crypto.org mainnet yet. (We haven't got the new archive nodes yet)

But Validators, Validator and ValidatorDelegations gRPC endpoints works well on croeseid-4 node. croeseid-4 is at about height 2,000,000. I am able to query historical states with the endpoints at around latest, 1,000,000 and 50,000.

[ysong42]

In the next step, we will try to port the logic from CosmosSDK to our repo.

Mainly for the following reasons:

1. Historical states are very important and useful to users. It will be great if the indexing server could provide it natively and not just proxy the requests to blockchain nodes.
2. When users' chain has upgrade(s) (using x/upgrade module), it will be difficult for them to set up multiple archive nodes.
3. Even if users could set up archive nodes, they will still need to pull the historical states to the indexing server. As when more requests come in, the underlying nodes may not be able to handle that.

[ysong42]

This will be a huge task. I plan to introduce a new projection and then let the projection support each message one by one.

The target of the new projection:

• Store Validator states in all height
• Store Validator Delegations states in all height
• Store Validator UnbindingDelegations states in all height
• Store Validator Redelegations states in all height

Steps:
- [ ] Problem: New validator projection. Handle MsgCreateValidator.
- [ ] Problem: New validator projection. Handle MsgDelegate.
- [ ] Problem: New validator projection. Handle MsgUndelegate.
- [ ] Problem: New validator projection. Handle MsgRedelegate.
- [ ] Problem: New validator projection. Handle slash event.

• Problem: New validator projection. Port main logic.
• Problem: New validator projection. Implement migration scripts and views.
• Problem: New validator projection. Result verification script.
• Problem: New validator projection. Missing unit tests.