search

crypto-com / chain-indexing

Other
35 stars 28 forks source link

Problem: Missing validator delegation in validator projection #161

Open calvinaco opened 3 years ago

ysong42 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

ysong42 commented 2 years ago

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 commented 2 years ago

https://github.com/cosmos/cosmos-sdk/discussions/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 commented 2 years ago

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 commented 2 years ago

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:

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.