63 lines
2.6 KiB
Markdown
63 lines
2.6 KiB
Markdown
# Store
|
|
|
|
The `store` package contains the implementation of store/v2, which is the SDK's
|
|
abstraction around managing historical and committed state. See [ADR-065](../../docs/architecture/adr-065-store-v2.md)
|
|
and [Store v2 Design](https://docs.google.com/document/d/1l6uXIjTPHOOWM5N4sUUmUfCZvePoa5SNfIEtmgvgQSU/edit#heading=h.nz8dqy6wa4g1) for a high-level overview of the design and rationale.
|
|
|
|
## Usage
|
|
|
|
The `store` package contains a `root.Store` type which is intended to act as an
|
|
abstraction layer around it's primary constituent components - state commitment (SC). It acts as the main entry point into storage for an
|
|
application to use in server/v2. Through `root.Store`, an application can query
|
|
and iterate over both current and historical data, commit new state, perform state
|
|
sync, and fetch commitment proofs.
|
|
|
|
A `root.Store` is intended to be initialized with already constructed SS and SC
|
|
backends (see relevant package documentation for instantiation details). Note,
|
|
from the perspective of `root.Store`, there is no notion of multi or single tree/store,
|
|
rather these are implementation details of SC. For SC, we utilize an abstraction, `commitment.CommitStore`,
|
|
to map store keys to a commitment trees.
|
|
|
|
## Upgrades
|
|
|
|
The `LoadVersionAndUpgrade` API of the `root.store` allows for adding or removing
|
|
store keys. This is useful for upgrading the chain with new modules or removing
|
|
old ones. The `Rename` feature is not supported in store/v2.
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
participant S as Store
|
|
participant SC as StateCommitment
|
|
alt SC is a UpgradeableStore
|
|
S->>SC: LoadVersionAndUpgrade
|
|
SC->>SC: Mount new store keys
|
|
SC->>SC: Prune removed store keys
|
|
end
|
|
SC->>S: LoadVersion Result
|
|
```
|
|
|
|
`PruneStoreKeys` does not remove the data from the SC instantly. It only
|
|
marks the store keys as pruned. The actual data removal is done by the pruning
|
|
process of the underlying SC.
|
|
|
|
## Migration
|
|
|
|
The migration from store/v1 to store/v2 is supported by the `MigrationManager` in
|
|
the `migration` package. See [Migration Manager](./migration/README.md) for more details.
|
|
|
|
## Pruning
|
|
|
|
The `root.Store` is NOT responsible for pruning. Rather, pruning is the responsibility
|
|
of the underlying commitment layer. This means pruning can be implementation specific,
|
|
such as being synchronous or asynchronous. See [Pruning Manager](./pruning/README.md) for more details.
|
|
|
|
|
|
## State Sync
|
|
|
|
The `root.Store` is NOT responsible for state sync. See [Snapshots Manager](./snapshots/README.md)
|
|
for more details.
|
|
|
|
## Test Coverage
|
|
|
|
The test coverage of the following logical components should be over 60%:
|