CAP 62 #1576
CAP 62 #1576
Conversation
| | [CAP-0057](cap-0057.md) | Smart Contract Standardized Asset (Stellar Asset Contract) Extension: Memo | Tomer Weller | Draft | | ||
| | [CAP-0057](cap-0057.md) | Soroban Live State Prioritization | Garand Tyson | Draft | |
There was a problem hiding this comment.
Weird upstream merge and wrong link in your CAP?
|
|
||
| ### XDR changes | ||
|
|
||
| ``` |
There was a problem hiding this comment.
This is usually rendered as a diff to make it easier to read 🤔
|
|
||
| #### Hot Archive BucketList | ||
|
|
||
| The Hot Archive is a BucketList that stores evicted `PERSISTENT` entries |
There was a problem hiding this comment.
nit: missing period
| The Hot Archive is a BucketList that stores evicted `PERSISTENT` entries | |
| The Hot Archive is a BucketList that stores evicted `PERSISTENT` entries. |
| Whenever an entry is restored via `RestoreFootprintOp`, the `LedgerEntry` being restored and its | ||
| associated TTL will be emitted as a `LedgerEntryChange` of type `LEDGER_ENTRY_RESTORE`. Note that | ||
| entries being restored may not have been evicted such that entries currently in the Live State BucketList | ||
| can see `LEDGER_ENTRY_RESTORE` events. |
There was a problem hiding this comment.
For this
Note that entries being restored may not have been evicted such that entries currently in the Live State BucketList can see
LEDGER_ENTRY_RESTOREevents.
I'd like to make sure I understand it correctly: Are you saying that LEDGER_ENTRY_RESTORE does not necessarily mean restoration from eviction because live state may have an expired-yet-not-evicted entry that can be restored before it pops off the end of the BL?
If yes, I'd like to suggest a rewording:
| Whenever an entry is restored via `RestoreFootprintOp`, the `LedgerEntry` being restored and its | |
| associated TTL will be emitted as a `LedgerEntryChange` of type `LEDGER_ENTRY_RESTORE`. Note that | |
| entries being restored may not have been evicted such that entries currently in the Live State BucketList | |
| can see `LEDGER_ENTRY_RESTORE` events. | |
| Whenever an entry is restored via `RestoreFootprintOp`, the `LedgerEntry` being restored and its | |
| associated TTL will be emitted as a `LedgerEntryChange` of type `LEDGER_ENTRY_RESTORE`. Note that | |
| entries can be restored from both the Live State and Hot Archive BucketList, because archived entries | |
| continue to exist in Live State until they are evicted as part of natural BucketList growth. The emitted | |
| meta does not distinguish between these. |
| The reasoning behind introducing CAP-0057 before it was strictly necessary was to prevent breakage of applications. If applications | ||
| and users were not prepared for State Archival, it would be very difficult to enable CAP-0057. However, because | ||
| [CAP-0046-12](./cap-0046-12.md) is implemented and State Archival semantics are already required, upgrading to CAP-0057 should not | ||
| be breaking, especially since much of the complexity, like proof generation, is handled automatically by RPC endpoints. |
There was a problem hiding this comment.
| be breaking, especially since much of the complexity, like proof generation, is handled automatically by RPC endpoints. | |
| be breaking, especially since much of the complexity, like proof generation, will be handled automatically by new Stellar Core HTTP endpoints. |
Is that correct? While RPC will be the facilitator via simulateTransaction, the proofs are actually generated by /getrestorationproof per stellar/go#5426, right?
| The rate of eviction (i.e. the rate at which state is added to the Hot Archive) can already be controlled | ||
| via network config settings. The rate at which state is added to the Live BucketList is also already |
There was a problem hiding this comment.
Can you elaborate on this? I was under the impression that eviction is controlled by state TTL rather than network configurations. Or is this referencing the eviction of already-archived entries in the live BL?
This CAP introduces "partial state archival".
Instead of deleting evicted state initially in protocol 23, I'm proposing only implementing the "Hot Archive" initially. This will allow prioritization of live Soroban state (as in caching all live state in memory). See more context here. Full State Archival will still be necessary long term, but can be implemented in a later protocol release.
This CAP discusses this Hot Archive implementation and related changes to the storage fee system.