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

Return block height when querying account balances #2296

Open
4 tasks
vwagner opened this issue Mar 11, 2025 · 1 comment
Open
4 tasks

Return block height when querying account balances #2296

vwagner opened this issue Mar 11, 2025 · 1 comment

Comments

@vwagner
Copy link

vwagner commented Mar 11, 2025

Summary

The Cosmos q bank balances query endpoint unfortunately does not return block height at which the returned balances were true. Add a new endpoint to return block_height along with account balance information.

Problem Definition

Because the q bank balance(s) queries do not return the block height at which the balance query was made, it is impossible to know an account balance at any block height without re-creating the entire history of the account. The best one can do is to query block height, then query bank balances, and hope that a block was not cut in between the two queries.

This issue came to mind when contemplating potential changes to an account's hash balance for the new tokenomics. How would one be able to query an account's balance at the moment of change before new tx potentially alter the balance, for example.

For context, my use case is generating reports on my company's daily hash usage for gas. In order to know the cost basis of any hash, I need to know the account balance at a given point in time.

Proposal

Return block_height in addition to balance(s) on account balance queries.

Since bank is a Cosmos module that Provenance has a fork of, perhaps we could add a query to it. Otherwise perhaps this query could more easily be added to the Marker module.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@iramiller
Copy link
Member

This is an interesting blur of the line between what a blockchain node is responsible for. Namely querying current state of the chain and determining f a set of changes are allowed in a transition to a new block. The design of the state and block stores is heavily biased for this primary purpose which is why the indexing and query performance is so terrible. It’s also why having an interval database of state even when modeled as an event stream is far superior for queries. The underlying database (Postgres?) is a fundamentally different structure that is optimized for querying.

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