Skip to content

Commit

Permalink
fix store readme
Browse files Browse the repository at this point in the history
  • Loading branch information
tac0turtle committed Dec 9, 2024
1 parent 70b5e7c commit 8a1502a
Showing 1 changed file with 6 additions and 12 deletions.
18 changes: 6 additions & 12 deletions store/v2/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,17 +7,15 @@ and [Store v2 Design](https://docs.google.com/document/d/1l6uXIjTPHOOWM5N4sUUmUf
## Usage

The `store` package contains a `root.Store` type which is intended to act as an
abstraction layer around it's two primary constituent components - state storage (SS)
and state commitment (SC). It acts as the main entry point into storage for 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 SS and SC. For SS, we utilize store keys
to namespace raw key/value pairs. For SC, we utilize an abstraction, `commitment.CommitStore`,
rather these are implementation details of SC. For SC, we utilize an abstraction, `commitment.CommitStore`,
to map store keys to a commitment trees.

## Upgrades
Expand All @@ -29,22 +27,18 @@ old ones. The `Rename` feature is not supported in store/v2.
```mermaid
sequenceDiagram
participant S as Store
participant SS as StateStorage
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
alt SS is a UpgradableDatabase
S->>SS: PruneStoreKeys
end
```

`PruneStoreKeys` does not remove the data from the SC and SS instantly. It only
`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 SS and SC.
process of the underlying SC.

## Migration

Expand All @@ -54,7 +48,7 @@ the `migration` package. See [Migration Manager](./migration/README.md) for more
## Pruning

The `root.Store` is NOT responsible for pruning. Rather, pruning is the responsibility
of the underlying SS and SC layers. This means pruning can be implementation specific,
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.


Expand All @@ -65,4 +59,4 @@ for more details.

## Test Coverage

The test coverage of the following logical components should be over 60%:
The test coverage of the following logical components should be over 60%:

0 comments on commit 8a1502a

Please sign in to comment.