Giulio2002
commented
1 week ago This was fixed in the most recent version, most nodes are running the previous version (2.59) which had multiple gossip bugs over p2p, and is very bugged from a P2P perspective. I just expect the other nodes to ban us. I think maybe for future version we can add the version to it
Description
Hey there folks! This issue is just to raise a concern about the interaction of the
Erigon/Caplinclient within the Ethereum CL p2p network.At ProbeLab, we’ve been running a Prysm node for a while, and we’ve been able to track some occasional
errorlog messages reporting the arrival of an invalid message ongossipsubtopics such asvoluntary_exitandattester_slashing.Without any chance of knowing which node and which client broadcasted the message first, we see that
erigon/caplinhas been forwarding them without any type of validation, and sharing it over itsgossipsubtopic mesh connections mpacts the peerscore, which generally ends up triggering sudden PRUNEs from all thegossipsubmeshes (we already experience a similar issue when running our toolHermesand we documented it in this post.This might not seem like a severe problem, but
Caplin’s connectivity could be impacted by this, leaving it without any stable connections in the gossipsub meshes.Do you guys have any idea of how could a light message verification be implemented at the
Caplinclient?System information
Erigon version:
erigon/caplinChain/Network:
MainnetExpected behaviour
Having invalid messages around is not an expected scenario. However, we can see that on some occasions, they do happen. Ideally, the
Erigon/Caplinsoftware should filter them out, as sharing them back to its directly connected peers can jeopardize its mesh connectivity.Actual behaviour
The measured errors look like this:
Steps to reproduce the behaviour
Unfortunately, to recreate the behaviour, we would have to propagate back an invalid message to the network, which could generate invalid traffic in the network.