[consistent-store] Index address balances #24713
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
wlmyng
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
| optional string owner = 1; | ||
|
|
||
| // Required. The marker type for the balance, e.g. `0x2::sui::SUI`. | ||
| optional string coin_type = 2; |
There was a problem hiding this comment.
do we want to use coin_type to refer to the inner T of both Balance<T> and Coin<T>?
| optional End end = 103; | ||
| } | ||
|
|
||
| message ListAddressBalancesResponse { |
There was a problem hiding this comment.
while these grpc types look very similar to Balances (soon-to-be CoinBalances), I think we should still keep them separate, given coin balances are something we'd hope to phase out, and address balances may undergo further evolution
| /// Submit a write for every checkpoint, for snapshotting purposes. | ||
| const MAX_BATCH_CHECKPOINTS: usize = 1; | ||
|
|
||
| /// No batching actually happens, because `MAX_BATCH_CHECKPOINTS` is 1. |
There was a problem hiding this comment.
this is directly lifted from the existing consistent-store pipelines
| let address_balances = &conn.store.schema().address_balances; | ||
|
|
||
| for (key, val) in batch { | ||
| if *val == 0 { |
There was a problem hiding this comment.
the balances handler has a compaction filter that drops entries with 0 balances. For AddressBalances, we don't have to calculate deltas and merge balances, as this is done on-chain, so we can directly use the balance information.
|
|
||
| /// All tables written to and read from the consistent store. | ||
| pub(crate) struct Schema { | ||
| /// Tracks ... address balances. |
There was a problem hiding this comment.
i'll return to this with a better doc comment!
wlmyng
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
… we want to order by coin type, potentially not aligned with how things are returned. or if we want to order by balance. and finally, for a reader, doing lookups against kv, then consulting consistent store, doesnt seem ergonomic
dont need (coin)balances-specific filtering logic
wlmyng
force-pushed
the
feature/h-implement-address-balances-consistent-reader
branch
from
4de3012 to
54998dd
Compare
wlmyng
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
wlmyng
requested review from
amnn,
emmazzz,
evan-wall-mysten,
henryachen,
nickvikeras and
tpham-mysten
wlmyng
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
wlmyng
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
wlmyng
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
Description
Add two new apis,
get_address_balanceandlist_address_balancesto the consistent store api service, backed up by a new column family/ index in the consistent store.While an individual balance can be looked up directly through on-chain data, listing an address's balances involves going to KV store to retrieve the bag id from the
AccumulatorOwnerdynamic field before using the existingobject_by_ownerindex to filterAccumulatorMetadata. Since the consistent-store does not store object contents, only object references, the actual data resolution then goes back to KV. As a first party feature, we choose to privilege this with an index as we do the existingbalancesderived from coin aggregations.Stack
balancesrelated API tocoin_balances.Test plan
New tests in
consistent_store_address_balance_tests.rs, WIP to be added to thsi PRRelease notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.