You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the rollout of State Archival, there will be significantly less state in the "Live BucketList" that actually needs to be queried during TX validation and application. Additionally, this amount of state is limited at the protocol level via config settings.
Due to this small, limited size, it makes sense to cache all live state in memory. While we won't be able to cache all state in production until classic entry types are evicted, we will be able to cache all Soroban entries. Additionally, this mode would be helpful in max TPS and catchup tests, where we can test future scenarios assuming classic entry eviction.
I think the best way to do this is to create a single map/some other structure that holds all ledger state in memory. On startup, this structure will be populated during the assumeState function call. All reads will be based on this cache, and all write/deletes will also be implemented (this should probably be handled by LedgerManager or LedgerTxnRoot). Note that we will still need to write all state to the BucketList. Additionally, offers will still need to be in SQL due to the indexes we require for the offer table. However, we can use an in-memory SQL DB for testing in this mode.
The text was updated successfully, but these errors were encountered:
With the rollout of State Archival, there will be significantly less state in the "Live BucketList" that actually needs to be queried during TX validation and application. Additionally, this amount of state is limited at the protocol level via config settings.
Due to this small, limited size, it makes sense to cache all live state in memory. While we won't be able to cache all state in production until classic entry types are evicted, we will be able to cache all Soroban entries. Additionally, this mode would be helpful in max TPS and catchup tests, where we can test future scenarios assuming classic entry eviction.
I think the best way to do this is to create a single map/some other structure that holds all ledger state in memory. On startup, this structure will be populated during the assumeState function call. All reads will be based on this cache, and all write/deletes will also be implemented (this should probably be handled by
LedgerManager
orLedgerTxnRoot
). Note that we will still need to write all state to the BucketList. Additionally, offers will still need to be in SQL due to the indexes we require for the offer table. However, we can use an in-memory SQL DB for testing in this mode.The text was updated successfully, but these errors were encountered: