chain_getBlockHash not implemented properly

[tomaka]

chain_getBlockHash is very problematic to implement. If the JSON-RPC client requests for example block number 2,000,000 while the head is for example around 9,000,000 then we have no reasonable way to know it.
Asking a full node for the block with that number works, but because we have no proof of ancestry we have no guarantee that this block is the correct one.

[rphmeier]

MMRs!

[xlc]

Without this it is impossible to iterate blocks so I would give this a bump on priority.

[tomaka]

This is unfixable before Beefy is shipped.

[gilescope]

If the head is 9,000,000 it would be nice if recent block numbers were supported. Presumably the hash of block 8,999,999 is known? If so it could be returned rather than the currennt None. Maybe it's hard to go all the way back but we must have cached some recent blocks and know their chain height?

[tomaka]

Recent block numbers are supported, but this is completely useless because there's no future-proof way to define "recent".

[gilescope]

Maybe I'm reading the runes wrong on this one but it looks like only 0 is supported; should it not care about the height parameter here if it is implemented:

smoldot/bin/light-base/src/json_rpc_service/state_chain.rs

Line 224 in 58c56ed

Some(_) => {

When I'm asking for the recent (as in within 1-2 blocks from the head that I know it should have history of) blocks I just seem to get null returned.

[tomaka]

Ah right, we used to look in the cache of recent blocks, but I intentionally removed that hastily after realizing that the cache of recent blocks could contain non-canonical blocks (i.e. can contain multiple blocks of the same number, without a way to know which one is on the best chain and which one isn't).

I can restore that behavior by improving the cache to store the canonical chain.