Getting historical ARC20 balance on a given block_height?

[bombnp]

Hi @atomicals, I'm looking for a way to query historical FT balance (get balance of all atomical_ids of an address at given block_height, NOT current balance), but I don't see a way to efficiently query for it (excluding fetching all transactions and replay all transfers).

If there isn't, I'm willing to submit a PR to index historical FT balance during block processing. I have some ideas in mind but I'd like to discuss with you guys first.

Idea

My idea is to add

• Key: b'hba' + address + atomical_id + height. Value: CBOR-serialized value of { "sat": int, "exp": int }, which is balance of token (sat x 10^exp). This key would be created when an address's balance of an atomical_id changes. This index is sparse too, so the it would only grow for each atomical_ids that changes in a block. The exp field would increase if it encounters a new UTXO with higher exponent, similar to coloring logic in atomicals_blueprint_builder.py.

To query address's balance on a block_height, just iterate on db with prefix = b'hba' + address with reverse = True. We capture the first occurrence of balance of each atomical_id where the height in key does not exceed the given block_height.

Optimization

To make the query even faster, we could add additional key b'fb' + address + atomical_id to store the first block_height that this address have a transaction that involves this atomical_id. Then we can iterate over this key to find all atomical_ids that we should query for this block, and use it to query over b'hba' key above with prefix = b'hba' + address + atomical_id, allowing us to skip iterating over multiple keys of the same atomical_id. This would trade high disk usage for faster query time for address with lots of transactions.

Note

If you guys have other ideas for me to implement, let me know.

[AlexV525]

It doesn't sound like a feature that should be implemented by the indexer, it'll also cost much to track between addresses. For some other businesses, set up a self-implemented indexer with the feature included could also help you to obtain those info.

[shadowv0vshadow]

In the latest code, you can query all assets and activities based on an address, and the returned information includes the height. You can use this information to perform some external processing. It doesn't seem necessary to include this logic in the indexer, as it would impose additional overhead.

[bombnp]

ah I must have missed #86. This is very similar to what I'm looking for. Thanks! @shadowv0vshadow