Store: Support Direct SS Writes

[alexanderbez]

Context

In the original store v2 ADR, we proposed functionality for modules to have the ability to directly write and read state that is outside of commitment, e.g. CW metadata or large blobs of data.

Proposal

We can easily support this by adding two APIs to the existing types:

type RootStore interface {
  // ...

  GetVersionedDatabase() VersionedDatabase
}

type VersionedDatabase interface {
  // ...

  Set(storeKey string, version uint64, key, value []byte) error
}

[tac0turtle]

what about a non consensus set, or MetadataSet that is documented to be outside of consensus? apps will be able to get the data per usual but there isnt a need to expose the version database interface to everything?

[alexanderbez]

Yes, this is what I'm alluding to. Allowing SS (VersionedDatabase) to directly store non-consensus data.

[tac0turtle]

ah, it looked like you were exposing the version database at the root level, which is why it was confusing. I dont think we should expose that level of detail, feels like a code smell

[alexanderbez]

Yes, of course. What I'd like is for the ability for modules to get direct access to the SS backend so they can call Set(...) and Get(...).

[tac0turtle]

is this still blocked?

[alexanderbez]

I would say it's blocked until we have a complete picture of server/v2 store/v2 integration. Is that complete? If so, we can discuss the following:

1. How do we allow modules to get direct access to SS s.t. it doesn't interfere with consensus state keys
2. How do we cleanly support snapshotting extensions

[tac0turtle]

this will be part of runtime/v2

[alexanderbez]

Once the design is settled, please let me know so I can document it in the store/v2 docs.

[tac0turtle]

should we make a service like we do kvstoreServices?

[alexanderbez]

Once the design is settled, please let me know so I can document it in the store/v2 docs.

Yes, that's what I had envisioned more or less. So a module would have as input Environment and from Environment it can say:

ncStore := env.GetNonConsensusStore(...) // I presume this is already scoped to the module's store key???
ncStore.Set(key, val)

One thing I've realizing is that we may need to handle rollbacks. E.g. if a module writes to non-consensus state during say a tx, but that tx later fails, should we roll it back?

[alexanderbez]

ref: #19721

[julienrbrt]

SS is gone since #22683
The non consensus store proposal is tracked by #19721