populate parent hash for indexers

[nbaztec]

What
Populates the parent hash to enable indexers in the rpc response.

Note
We have been maintaining this functionality in our custom fork for a long time know, and would like to discuss around it if it makes sense for upstream as well.

/cc @tgmichel

[sorpaas]

It's a bug if currently parent hash is not populated other than genesis block.

[sorpaas]

Some basic testing didn't reproduce the issue for me. Appreciate it that you can submit a bug report issue with more details of exactly which situations you are not getting the parent hashes.

This PR is definitely not the right way though.

[tgmichel]

@sorpaas this is an old patch we need to have in our fork to solve the bug that was introduced in #570 (context explained there). So is a patch to fix, at most, a single block.

Basically means that, in the case the retrieved on-chain parent_hash is H256::default() - which was the case as described in #570 - we calculate it on the fly to build the rpc response.

We hope to have this upstream, and not to have to cherrypick it forever on our side.

[sorpaas]

Please hard code those problematic blocks instead:

• Create a config option forced_parent_hashes to be a mapping of block hash to parent block hash.
• And then just check in the function to force set parent hash if the block hash matches.

[nbaztec]

• forced_parent_hashes

Should we use the newly added EthConfig trait for this? Something like:

pub trait EthConfig<B: BlockT, C>: Send + Sync + 'static {
	type EstimateGasAdapter: EstimateGasAdapter + Send + Sync;
	type RuntimeStorageOverride: RuntimeStorageOverride<B, C>;

       // new
       type ForcedParentHashProvider: Get<HashMap<B::Hash, B::Hash>>
}

[nbaztec]

• forced_parent_hashes

Should we use the newly added EthConfig trait for this? Something like:

pub trait EthConfig<B: BlockT, C>: Send + Sync + 'static {
	type EstimateGasAdapter: EstimateGasAdapter + Send + Sync;
	type RuntimeStorageOverride: RuntimeStorageOverride<B, C>;

       // new
       type ForcedParentHashProvider: Get<HashMap<B::Hash, B::Hash>>
}

@sorpaas ?

[sorpaas]

Should we use the newly added EthConfig trait for this?

This is up to you. Either a type parameter in EthConfig trait or as a config parameter when initializing RPC. Check which works best for your use case.

One potential issue making this a type parameter is that it can't be customized "dynamically". This can happen, for example, when you need to start multiple chains based on the same type parameters.

[nbaztec]

@sorpaas your suggestion made good sense since multiple chains based on same start code, are now able to pass in their own block hashes seamlessly.

[boundless-forest]

This solution LGTM.

Another question is that can we use the db cmd to fix the ethereum block hash storage associated with the broken block hash mapping? Seems another doable way.

[sorpaas]

Another question is that can we use the db cmd to fix the ethereum block hash storage associated with the broken block hash mapping? Seems another doable way.

The wrong hash is in the runtime storage, so it stays permanently in the blockchain.