-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
server/v2/stf should not manage the storage and retrieval of header info #20510
Comments
closing this as it was discussed in slack |
Still, this is bad design: // TODO reserved in consensus OR need a keeper here
const headerInfoPrefix = 0x37
// setHeaderInfo sets the header info in the state to be used by queries in the future.
func (s STF[T]) setHeaderInfo(state store.WriterMap, headerInfo header.Info) error {
// TODO storing header info is too low level here, stf should be stateless.
// We should have a keeper that does this.
runtimeStore, err := state.GetWriter(appmanager.ConsensusIdentity)
if err != nil {
return err
}
bz, err := headerInfo.Bytes()
if err != nil {
return err
}
err = runtimeStore.Set([]byte{headerInfoPrefix}, bz)
if err != nil {
return err
}
return nil
} stf is arbitrarily picking a byte prefix within the consensus merkelized tree (should this even be merkelized?). There could be collisions (since that byte prefix is not reserved) if consensus changes the disk layout of its keys. |
In the past store did this automatically. I'm not sure store supports this out of the box. There was a space in which commit info was stored. We should try to recreate this. Agree this is not a good design. Cc @testinginprod |
(note this is my opinion) Why should STF not store it? I do not understand, for instance, HeaderInfo is a first classi citizen of every API, it lives in So it's not something that can or cannot exist, header info will be always there, no matter how we change modules, or consensus. If this is not a correct assumption then So who should store this info? The Consensus Engine holds this info, then how does Consensus Engine plumb this into the execution context?
Regarding having this Merklized or not: Modules need historical headers in order to server historical queries. The "old way" of doing it would also force store to save all the headers versions in state, which is fundamentally the same as having it merklized. It is also one less exception that store needs to handle, since saving historical queries it's ALWAYS needed there's no reason for storage implementations to specialize around this use-case. The argument could be: why should STF save into the "Consensus" namespace, with that I agree, we can create a "_stf" namespace which is local to stf itself and cannot be claimed by other actors. TLDR:
|
what is the outcome here? should we remove this or keep it? |
STF is stateless, the current iteration manages storing header info, and is borrowing the consensus key to do so. STF should instead depend on a header service which abstracts storage.
cosmos-sdk/server/v2/stf/stf.go
Lines 414 to 416 in f235226
The text was updated successfully, but these errors were encountered: