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

querying total stake and voting powers for past epochs #3810

Open
egasimus opened this issue Sep 12, 2024 · 2 comments
Open

querying total stake and voting powers for past epochs #3810

egasimus opened this issue Sep 12, 2024 · 2 comments

Comments

@egasimus
Copy link
Contributor

egasimus commented Sep 12, 2024

In order to independently compute proposal results, we need to fetch voting power for each vote of each past governance proposal. To achieve this, it appears that we need the following data for each past epoch:

  • total NAM staked on chain
    • Expected: ABCI query /vp/pos/total_stake/5000 returns total staked amount at epoch 5000
    • Actual: ABCI query /vp/pos/total_stake/5000 returns 0n
  • list of validators
    • Expected: ABCI query /vp/pos/validator/addresses/5900 returns list of validators at epoch 5900
    • Actual: ABCI query /vp/pos/validator/addresses/5900 returns an empty list.
  • stake amount of each validator
    • same as above (possibly different epoch count)
  • bond amount of each delegator
    • same as above (possibly different epoch count)

As far as I understood from epoched.rs, the Epoched struct only keeps data for a fixed number of past epochs. Could you explain why this is the case and whether there is a workaround for fetching historical data from the node?

@Fraccaman
Copy link
Member

Hi @egasimus! Right now, this is a limitation of namada. We "prune" some of the PoS data each epoch, meaning that the data you are looking for its not easily accessible and requires a more complex mechanism to query it. Unfortunately, this is not a priority for us right now and we won't look into it in the short future.
As a workaround, you start a fullnode from scratch and while the fullnode is synching, you can connect an indexer.

Ill' leave the issue open and update it as soon as we start working on this.

@egasimus
Copy link
Contributor Author

Thanks! Fair enough. For the workaround, doesn't that mean a race between the fullnode sync and the indexer? Doesn't sound very reliable. it would be massively helpful if the node at least returned an error that the queried data has been pruned, rather than just returning empty values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants