Validator client HTTP API wouldn't start without a beacon node

[chong-he]

Description

Starting lighthouse vc –http alone wouldn’t start the validator client HTTP API. HTTP API queries will get connection refused.

Once lighthouse bn –http is started, only then the validator client logs INFO HTTP API started and HTTP API queries works. If the bn is stopped afterwards, the validator client HTTP API calls still work.

From @michaelsproul, the reason being that the validator client waits to fetch genesis from the BN on start-up here:

lighthouse/validator_client/src/lib.rs

Lines 384 to 388 in 441fc16

	// Perform some potentially long-running initialization tasks.
	let (genesis_time, genesis_validators_root) = tokio::select! {
	tuple = init_from_beacon_node(&beacon_nodes, &proposer_nodes, &context) => tuple?,
	() = context.executor.exit() => return Err("Shutting down".to_string())
	};

Version

Lighthouse v4.5.0-441fc16

Present Behaviour

Starting lighthouse vc –http alone wouldn’t start the validator client HTTP API

Expected Behaviour

Starting lighthouse vc –http alone should start the validator client HTTP API

Steps to resolve

From @michaelsproul, a possible solution is to refactor that so that the validator client just gets those values (or from the hardcoded genesis state in the network config)

[michaelsproul]

Related:

• [Merged by Bors] - validator client: start http api before genesis #4714

I don't think that PR caused a regression, but it didn't fully solve the issue (in the offline BN case)

[Nanle100]

is this issue still open?
I'd love to walk on it

[chong-he]

is this issue still open? I'd love to walk on it

Yes it's still open.

The reason that VC waits for the beacon HTTP is to get the genesis and chain info so that VC can function. So the solution is to how to let the VC figuring out how to get those info without the beacon node

[Nanle100]

Okay!
let me try to work this issues