querying total stake and voting powers for past epochs

[egasimus]

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]

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]

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.

[opsecx]

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.

I'm curious, would running a node with indexer = kv disrupt this pruning? or unrelated?

[opsecx]

@Fraccaman having this data available seems like a big net gain for the "indexing community" - any chance it could be given some priority? (not top ofc but also included at some point)

[brentstone]

@opsecx I'm not super familiar with the technical details of indexers, but I think I can offer some insight here:

The pruning occurs in the protocol, so no indexer setting would be able to disrupt or change it. However, an indexer or similar service could cache these pieces of data elsewhere while it reads them as they still exist in Namada and then persist them after they've been pruned from the namada DB.