node-real / bsc-erigon

Ethereum implementation on the efficiency frontier

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Possibility of PenalizePeer Being Too Strict

temuera opened this issue · comments

I guss that PenalizePeer may be too strict when using the drop-useless-peers parameter (or not using it).

there is a recurring phenomenon on multiple nodes:

After restarting a node, it efficiently synchronizes to the highest block.

After an unspecified period of time, the message "...to write in this log period" appears. At this point, the node will stop synchronizing or fall behind in height.

Restarting the node again will restore sync with high speed.

In the code, the sentry.PenalizePeer function is used to filter out invalid nodes (in multiple places). The detection logic involves if a single RLP decoding fails or returns an invalid BlockHeader, among other criteria.

Can consider using an internal LRU as a counter for valid node data? Resetting it when valid data is returned.

I'm not certain if this is correct. However, I suspect that under normal circumstances, peers cannot guarantee returning valid data every time, but rather sporadically.

Yes, you are right. we don't suggest use drop-useless-peers flag. Because it is valid to return empty responses. When you restart and sync to the highest block, and then the peer will have a period(3s) to wait for the next block. So when use this flag you may penalize the good peer. And it's hard to find another good peer, because most peer in main net don't broadcast new block and there is no way to drop those peers. So we hardcode the static peers in the binary.

@blxdyx Thank you for reply. I'm not sure about the correct usage of static nodes:

Is it theoretically possible for a geth full node supporting eth66,67 protocols to communicate with Erigon and provide the latest block header notifications?

When adding a geth full node as a static node in Erigon, do we also need to add the Erigon peerUrl in the geth full node as a static node? Both directions?

@blxdyx Thank you for reply. I'm not sure about the correct usage of static nodes:

Is it theoretically possible for a geth full node supporting eth66,67 protocols to communicate with Erigon and provide the latest block header notifications?

When adding a geth full node as a static node in Erigon, do we also need to add the Erigon peerUrl in the geth full node as a static node? Both directions?

  1. Yes
  2. No

You can try the v1.2.0-beta. It have remove the drop-useless-peers.

You can try the v1.2.0-beta. It have remove the drop-useless-peers.

I will be setting up a new node to test restoring from a snapshot of 33620K with 1.20beta.