Gnosis Pectra hardfork minor issues

[dapplion]

Two minor issues found during Gnosis Pectra hardfork

Lightclient production error - To be fixed ⚠

For each block until we finalized the fork epoch we got lightclient production errors

Apr 30 14:03:51.375 ERRO error computing light_client updates LightClientUpdateError(BeaconStateError(IncorrectStateVariant)), service: lc_update, module: client::compute_light_client_updates:31
...
Apr 30 14:07:42.131 ERRO error computing light_client updates LightClientUpdateError(BeaconStateError(IncorrectStateVariant)), service: lc_update, module: client::compute_light_client_updates:31

Subscribe NotAllowed - NON-ISSUE ✅

Once, 2 slots before the fork slot we attempted to subscribe to some topics and got NotAllowed

Apr 30 14:03:30.001 WARN Failed to subscribe to topic, error: NotAllowed, topic: /eth2/7d5aab40/blob_sidecar_5/ssz_snappy, service: libp2p, module: lighthouse_network::service:797
Apr 30 14:03:30.001 WARN Failed to subscribe to topic, error: NotAllowed, topic: /eth2/7d5aab40/blob_sidecar_2/ssz_snappy, service: libp2p, module: lighthouse_network::service:797
Apr 30 14:03:30.002 WARN Failed to subscribe to topic, error: NotAllowed, topic: /eth2/7d5aab40/blob_sidecar_3/ssz_snappy, service: libp2p, module: lighthouse_network::service:797
Apr 30 14:03:30.002 WARN Failed to subscribe to topic, error: NotAllowed, topic: /eth2/7d5aab40/blob_sidecar_4/ssz_snappy, service: libp2p, module: lighthouse_network::service:797
Apr 30 14:03:40.001 INFO Transitioned to new fork, new_fork: Electra, old_fork: Deneb, service: network, module: network::service:88

It's this line from the gossipsub behaviour

        if !self.subscription_filter.can_subscribe(&topic_hash) {
            return Err(SubscriptionError::NotAllowed);
        }

https://github.com/libp2p/rust-libp2p/blob/2dc453bcc435d0d664f0b31c679ae1ebda4bf16a/protocols/gossipsub/src/behaviour.rs#L527C1-L529C10

Ah, it's probably because in Gnosis the subnet count reduced from 6 to 2, so we can't roll those topics over. It will be a non-issue for Mainnet.

[michaelsproul]

Didn't we downgrade the severity of that LC log to Debug?

[eserilev]

There seems to be a second place where this log message can occur and we only downgraded the first one

I'm also pretty sure the error itself originates from us computing LightClientFinalityUpdate objects at fork boundaries.

[michaelsproul]

Another one is the logging of ERROR messages for bad attestations:

https://discord.com/channels/605577013327167508/605577013331361793/1367196295147819152

May 01 01:50:24.665 ERRO Unable to validate attestation error: AttestationValidationError(BeaconStateError(EmptyCommittee)), peer_id: 16Uiu2HAmNssnwh9getpGCLg3wVzwqef9bUg1cu6mizCx88zjCdCY, type: "aggregated", slot: Slot(21414176), beacon_block_root: 0x9c888c7bead0c8bbf47862c3dad512015bdedc2bc275b707ffee7122d3116e6e

This is because we don't have explicit handling of the EmptyCommittee error variant here:

lighthouse/beacon_node/network/src/network_beacon_processor/gossip_methods.rs

Lines 2879 to 2894 in e42406d

	/*
	* Lighthouse hit an unexpected error whilst processing the attestation. It
	* should be impossible to trigger a `BeaconChainError` from the network,
	* so we have a bug.
	*
	* It's not clear if the message is invalid/malicious.
	*/
	error!(
	self.log,
	"Unable to validate attestation";
	"beacon_block_root" => ?beacon_block_root,
	"slot" => ?failed_att.attestation_data().slot,
	"type" => ?attestation_type,
	"peer_id" => %peer_id,
	"error" => ?e,
	);

We should add that. But we should also track down which clients are sending these attestations and tell them about the bug.

The impact is minimal: we just don't penalise these peers when we should, and we log that unsightly error.