Follow-up from PR comment: #2012 (review)
When GetAccount handles an AllEntries storage-map request, it first tries to read entries from the account state forest. This works only if every hashed_key -> raw_key mapping is present in the forest reverse-key LRU cache. If any mapping is missing, the current code falls back to reconstruct_storage_map_details_from_db(), which reconstructs the full storage map from the DB and then backfills the cache.
There may be a more targeted fallback here. Instead of reading full map details from the DB when only some reverse-key cache entries are missing, we could fetch or reconstruct only the missing key mappings.
Potential approaches:
- Add a DB helper such as
get_storage_map_key_mapping(account_id, slot_name, block_num, hashed_keys) that returns raw keys for the missing hashed keys.
- Store hashed keys in
account_storage_map_values, for example as an additional column, so missing mappings can be queried directly.
- Alternatively, since all-entries responses are bounded by
AccountStorageMapDetails::MAX_RETURN_ENTRIES currently 1000, read the raw keys for the map and hash them locally to recover only the missing mappings.
The main tradeoff is complexity and storage overhead versus avoiding full DB reconstruction on partial cache misses. This issue should explore whether the optimization is worthwhile and, if so, what API/schema shape would be appropriate.
Follow-up from PR comment: #2012 (review)
When
GetAccounthandles anAllEntriesstorage-map request, it first tries to read entries from the account state forest. This works only if everyhashed_key -> raw_keymapping is present in the forest reverse-key LRU cache. If any mapping is missing, the current code falls back toreconstruct_storage_map_details_from_db(), which reconstructs the full storage map from the DB and then backfills the cache.There may be a more targeted fallback here. Instead of reading full map details from the DB when only some reverse-key cache entries are missing, we could fetch or reconstruct only the missing key mappings.
Potential approaches:
get_storage_map_key_mapping(account_id, slot_name, block_num, hashed_keys)that returns raw keys for the missing hashed keys.account_storage_map_values, for example as an additional column, so missing mappings can be queried directly.AccountStorageMapDetails::MAX_RETURN_ENTRIEScurrently 1000, read the raw keys for the map and hash them locally to recover only the missing mappings.The main tradeoff is complexity and storage overhead versus avoiding full DB reconstruction on partial cache misses. This issue should explore whether the optimization is worthwhile and, if so, what API/schema shape would be appropriate.