Changelog
- Jan 19, 2022: Initial Draft
- Apr 29, 2022: Safer extension snapshotter interface
Status
ImplementedAbstract
This ADR outlines a hooks-based mechanism for application modules to provide additional state (outside of the IAVL tree) to be used during state sync.Context
New clients use state-sync to download snapshots of module state from peers. Currently, the snapshot consists of a stream ofSnapshotStoreItem and SnapshotIAVLItem, which means that application modules that define their state outside of the IAVL
tree cannot include their state as part of the state-sync process.
Note, Even though the module state data is outside of the tree, for determinism we require that the hash of the external data should
be posted in the IAVL tree.
Decision
A simple proposal based on our existing implementation is that, we can add two new message types:SnapshotExtensionMeta
and SnapshotExtensionPayload, and they are appended to the existing multi-store stream with SnapshotExtensionMeta
acting as a delimiter between extensions. As the chunk hashes should be able to ensure data integrity, we don’t need
a delimiter to mark the end of the snapshot stream.
Besides, we provide Snapshotter and ExtensionSnapshotter interface for modules to implement snapshotters, which will handle both taking
snapshot and the restoration. Each module could have mutiple snapshotters, and for modules with additional state, they should
implement ExtensionSnapshotter as extension snapshotters. When setting up the application, the snapshot Manager should call
RegisterExtensions([]ExtensionSnapshotter…) to register all the extension snapshotters.
multistore snapshot is always placed at the beginning of the binary stream, and other extension snapshots are alphabetically ordered by the name of the corresponding ExtensionSnapshotter.
The snapshot stream would look like as follows:
extensions field to snapshot Manager for extension snapshotters. The multistore snapshotter is a special one and it doesn’t need a name because it is always placed at the beginning of the binary stream.
ExtensionSnapshotter interface, their names should be registered to the snapshot Manager by
calling RegisterExtensions when setting up the application. The snapshotters will handle both taking snapshot and restoration.
Snapshotter interface for the multistore, we add ExtensionSnapshotter interface for the extension snapshotters. Three more function signatures: SnapshotFormat(), SupportedFormats() and SnapshotName() are added to ExtensionSnapshotter.
Consequences
As a result of this implementation, we are able to create snapshots of binary chunk stream for the state that we maintain outside of the IAVL Tree, CosmWasm blobs for example. And new clients are able to fetch sanpshots of state for all modules that have implemented the corresponding interface from peer nodes.Backwards Compatibility
This ADR introduces new proto message types, add anextensions field in snapshot Manager, and add new ExtensionSnapshotter interface, so this is not backwards compatible if we have extensions.
But for applications that does not have the state data outside of the IAVL tree for any module, the snapshot stream is backwards-compatible.
Positive
- State maintained outside of IAVL tree like CosmWasm blobs can create snapshots by implementing extension snapshotters, and being fetched by new clients via state-sync.
Negative
Neutral
- All modules that maintain state outside of IAVL tree need to implement
ExtensionSnapshotterand the snapshotManagerneed to callRegisterExtensionswhen setting up the application.