State Commitment (SC) API PoC

[alexanderbez]

The purpose for this issue is to produce a API PoC for State Commitment.

We want to be able to have the SC layer to act independently without any significant changes to the access patterns or behaviour. But also we would like the existing IAVL-backed module KVStores will act as the SC layer

There are 4 options so far for implementation

• iavl v0.21.1 (legacy node hash key format) backed by leveldb
• iavl v1, current master (version|sequence key format) backed by leveldb
• crypto-org-chain/cronos/memiavl
• iavl v1 backed by an in-memory hash map "mapDb" (for comparison)
• experimental iavl "version 2", avlite branch of cosmos-sdk/iavl.

Firstly, the benchmarks are being produced for the above, which will be followed by a decision as to which implementation will be used from the above list.

Currently the benchmarks and data set used can be found here

API

Beta Give feedback

1. CRUD
2. Pruning
3. (Reverse)Iteration
4. Snapshots
5. Proofs

[alexanderbez]

The API for SC should roughly support the following:

• CRUD
• Pruning
• (Reverse)Iteration
• Snapshots
• Proofs

[tac0turtle]

how is pruning and snapshotting being handled? separate interface, behind the scenes of an interface or?

[cool-develope]

we discussed those are handled in the root multi-store but will only manage the config of pruning and snapshotting, and the dedicated db backend will be responsible for the detailed flow.

[alexanderbez]

Yeah that more or less sounds accurate @cool-develope 👍

I think the general flow is:

• The SS interface (VersionedDatabase) has a Prune() method
• Some sort of config is passed to the (default) multi-store impl and will automatically handle pruning of SS

I'm not really sure about SC though...perhaps we just pass the config to the SC implementation and let it do its thing

[alexanderbez]

I think we can close this since we have a PoC API for SC (commitment) package.