latest finalized block metrics

[dhaidashenko]

Added metric to track latest finalized block observed by an RPC.
TIcket has more details.

This PR only introduces metric and does not include latest finalised block into health assessment of an RPC.
We plan to introduce it separately. Here is ticket for tracking

[patrickhuie19]

Can you help me reason through why this configuration belongs to ChainConfig vs NodeConfig or if ChainConfig is living in the correct place (vs in MultiNode)?

I'd expect configuration here to be node specific and for chain details to live at a higher level in the abstraction hierarchy, or for node to store a map[string]*ChainConfig to support multiple chain configurations

[dhaidashenko]

FinalizedBlockPollInterval belongs to NodeConfig and defines how often a Node instance should poll for a new finalized block. It's not a property of a chain; it's a property of the component that performs the health assessment of an RPC.

Node is responsible for the health assessment of a single RPC that works only with one chain. Node does not store map[string]*ChainConfig as there is no reason for it to be aware of other chain configurations.

[prashantkumar1982]

Just wondering, do we need different configs for each type of poll?
What if we just reuse the PollInterval for all polling?

[prashantkumar1982]

In some chains, we may also look for new heads via polling, not via subscribe.
In that case too, we wouldn't like to poll separately for new heads and new finalized heads. Mostly just make a single batch call to get both.
So that's why I am thinking, could we club all things to be polled under a same config, and fetch them together in a batch call?

[mateusz-sekara]

I have a similar impression, it would be more efficient to batch whenever we can instead of introducing a new ticker that will increase pressure on the RPC. AFAIK we already poll RPC to verify if it's healthy so probably we could use that logic for adding latest finalized block. If we manage to bundle that together into a single batch then we will get finality tracking for free

Maybe reusing existing <-pollCh?

	for {
		select {
		case <-n.nodeCtx.Done():
			return
		case <-pollCh:

[dhaidashenko]

I'm not in favour of merging all of the polls into a single ticker, as they check different properties of the RPC.
Poll checks that RPC is reachable, this is super basic check and we want to do it often and be aggressive with the timeouts, if an RPC needs > 1s to return it's version, it not healthy, while for finalized block it seems ok.

Regarding the new heads polling, it makes sense to batch poll in this case.

[prashantkumar1982]

Won't the NewTicker() panic if the parameter is 0?
I think in the fallback file, you should choose a default same as Eth mainnet, that's maybe 5 seconds?
Also, in config validation, ensure that this value is more than 0.

[dhaidashenko]

Won't the NewTicker() panic if the parameter is 0?

Yes, the NewTicker panics if the parameter is 0, that's why we do not initialize it unless provided value is > 0

I think in the fallback file, you should choose a default same as Eth mainnet, that's maybe 5 seconds?

Sounds good.

Also, in config validation, ensure that this value is more than 0.

IMHO, it should be possible to disable the check. Other health checks are optional, I do not see why this one should be an exception

[cl-sonarqube-production]

Quality Gate passed

Issues
2 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
97.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[amit-momin]

LGTM! I haven't been too involved in multinode changes but the config builder and chain client changes look good.