a86c2a9980
Co-authored-by: cool-developer <51834436+cool-develope@users.noreply.github.com> Co-authored-by: Marko <marbar3778@yahoo.com> Co-authored-by: sontrinh16 <trinhleson2000@gmail.com> |
||
|---|---|---|
| .. | ||
| commitment | ||
| db | ||
| errors | ||
| internal/encoding | ||
| metrics | ||
| migration | ||
| proof | ||
| root | ||
| snapshots | ||
| storage | ||
| batch.go | ||
| CHANGELOG.md | ||
| changeset.go | ||
| database.go | ||
| go.mod | ||
| go.sum | ||
| options.go | ||
| README.md | ||
| sonar-project.properties | ||
| store.go | ||
| trace.go | ||
| validation.go | ||
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
and Store v2 Design for a high-level overview of the design and rationale.
Migration
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,
such as being synchronous or asynchronous.
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
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,
to map store keys to a commitment trees.