Skip to content

state: streamline initialising of state #6071

@cmwaters

Description

@cmwaters

Summary

The part of the process of startup, where we load the latest state or if there is none, load the state from the provided genesis file seems a bit convoluted. I have a two proposals that I would like to illustrate why I think it's a bit convoluted and how we can simplify this: a) a subtle change b) a non-subtle change

Proposal

The Subtle Change

We have two functions loadGenesisDoc and saveGenesisDoc which are used to save the genesis doc to the state store. However, these are separate from the state store itself. If they are part of the state store, then they should be added to the interface so it's clearer that the genesis is being stored there.

LoadFromDBOrGenesisFile and LoadFromDBOrGenesisDoc seem to be slightly awkward functions. First off, we save genesis to the same store yet when it comes to loading it we have add it as an argument (and don't actually check if we already have it stored). I would also argue that this check should not happen in the store itself. The state store should be just responsible for storing and retrieving state. The logic to build state from the genesis doc should happen within the node package.

The Non-Subtle Change

I am not sure why we need to save the genesis to the state store in the first place. It's already persisted as a json in the config folder (or wherever developers put it when they run Tendermint programatically). The point is that the genesisDocProvider should be responsible for providing it and the flow on startup should be as follows:

  1. Try to load state from the state store. If it's there, good! we return state immediately

  2. If it's not there we get the genesisDocProvider to create a genesis doc

  3. We validate and complete the given genesis doc

  4. We make state from the genesis doc, and return it

  • A possible downside from this approach is that we potentially mutate the genesis doc when we go to complete it (but this has always been the behavior)

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions