docs: improved docs and logging for migrations from-ipfs

[m0ar]

Heya 👋

IPFS migration

I did a pass over the docs and logging to make it a bit easier to understand what's going on, after being confused more times than I care to admit with failing block imports (mostly related to incorrect paths in the input_file_list causing silent skips of the entire block set).

Took a swing at explaining some of the new validation options as well, LMK if something is factually incorrect!

RPC URLs config

Additionally, I got bitten by the fact that the --ethereum_rpc_urls flag/var seems to accept multiple endpoints, but in reality ignores everything after the first valid one. That's now made clear in the docs too. A potentially better fix would be to just accept a single one in config, but I chose to play defensively and not risk breaking startup for existing configs.

[smrz2001]

I believe the code uses the first RPC URL to return a successful result but continues iterating through the rest until it finds one that succeeds, or all of them fail.

[m0ar]

Yes, but I think this is only run when the TimeEventValidator is constructed, not every time it tries to validate an event, and it returns a hashmap which can only have one entry per key (which is the chain ID).

So what's happening here is that when starting the daemon, it checks if the first RPC URL can respond with it's own chain ID (see HttpEthRpc below). If so, it's set in a hashmap where the chain ID is the key, hence only one provider per chain ID is set in chain_providers.

Hence, when it's time to validate it just checks if there is a (as in one) provider for that chain ID, and uses it for the check:

[m0ar]

Oh also I did reproduce this behavior when switching to the blastapi RPC Nathaniel recommended. If that RPC URL is first, the node can sync, but if I flip it it fails just like if I only had the Ankr one set. I'd say this matches up with how I read the code above, if there isn't something else going on 👀

[dav1do]

So we can support multiple RPC endpoints, but like you point out we only use one per chain. That is, if we have time events that were anchored on ethereum mainnet and recall, we'd need two RPC urls so that we can verify time events for both chains. We don't currently support multiple endpoints for a single chain (e.g. to round robin for eth mainnet).

[stbrody]

@smrz2001 what's the status of this PR? Can this be closed?

[smrz2001]

@smrz2001 what's the status of this PR? Can this be closed?

Let me discuss this with @m0ar.

[m0ar]

@stbrody @smrz2001 Hey guys, sorry for snoozing on this. I've applied the suggestions :)

[smrz2001]

🚀