How to query the genesis state root hash?

[josepot]

I believe there are scenarios where users of the chainHead group of functions might benefit from querying the header of the genesis block or, at least, its state root hash. As per my understanding of the current specification, this doesn't seem possible.

@tomaka, would it be accurate to say that if a "server" supports the chainHead suite of functions, it should inherently be capable of providing the genesis state root hash?

[tomaka]

What's the use case of having the genesis state root hash?

would it be accurate to say that if a "server" supports the chainHead suite of functions, it should inherently be capable of providing the genesis state root hash?

That's not accurate no. There's absolutely no relationship between the genesis block and the head of the chain, except for the fact that the genesis hash (not the state root hash, the hash of the entire header) is sent over the peer-to-peer network when you connect to someone in order to make sure that they're on the same chain.

[josepot]

What's the use case of having the genesis state root hash?

My use case is to programatically convert a chain-spec with genesis.raw into one with genesis.stateRootHash. While this is a niche scenario, in my specific situation, I'm assured of interacting with smoldot. In retrospect, this issue might have been more apt the smoldot repo, but I posited that there might be additional use cases for accessing the header of the genesis block.

With smoldot, there are currently two ways -that I can think of- to retrieve this value:

1. Through the legacy JSON-RPC API (using chain_getHeader upon receiving the first initialized event of chainHead_unstable_follow with withRuntime set to true)
2. By extracting the value from the stdout of the smoldot process 🙈.

The latter is clearly an implementation-based hack, and the former is not ideal if we're looking towards deprecating the legacy JSON-RPC API.

Given that the new JSON-RPC API in smoldot doesn't allow access to the genesis header's properties, like the legacy one does, I wondered if there might be an oversight or something lacking in the new API.

[tomaka]

An appropriate way to query this would be a function in the chainSpec namespace.

However, I (soon) want to add a JSON-RPC function that lets you query an optimized version of the chain spec. The primary objective is that it would contain a checkpoint, but we can also make it so that the chain spec being returned is minimal.
smol-dot/smoldot#1186

[lexnv]

We would also want to fetch demo chain specs and optimize them to ensure smoldot could boot as soon as possible (ie changing genesis.raw to stateRootHash paritytech/subxt#1263).

Having a similar method in the chainSpec namespace would also simplify things from subxt side.

Looking at transforming genesis.raw to stateRootHash, we'd need the trie::calculate_root::root_merkle_value(trie::HashFunction::Blake2) of the genesis.raw.

I'm not sure at the moment if the stateRootHash could be extracted directly from the db in the substrate realm (and correspond to what smoldot expects), although I would think its a good idea to cache this information for a while if we don't have direct access to it (a few blocks, a minute etc).

[tomaka]

To me the path forward is to retrieve "optimized" chain specs as a whole. This way, you also obtain the current checkpoint through the same mechanism, which also speeds up the warp syncing.
I don't think that the concept of "state root hash" should be something that API users should ever be concerned with.

I'm not sure at the moment if the stateRootHash could be extracted directly from the db in the substrate realm (and correspond to what smoldot expects)

The genesis state root hash can be found in the genesis block header.