Optimisation: accept out-of-order p2p blocks from new proposer during rotation

[omritoptix]

Quoting @srene:

I'd like to:
1 - see what are all the rotation cases and make sure that nothing breaks regarding signature validation when rotation.
2 - see what are the implications of all cases to syncing from p2p and understand if in some cases p2p will need to be paused, for instance.
3 - list what is missing in terms of implementation.

[srene]

related to #1112

[srene]

also check e2e test with edge cases for sequencer rotation

[omritoptix]

@srene as far as I understand there is no issue there?

[srene]

if im not wrong, p2p gossip packets will be rejected in case of nodes are still syncing (because rotation packet is not applied yet and signature validation will fail). imo what it still needs to be done is :
1- do some research whether rejecting gossiped packets can be avoided when rotation for nodes syncing.
2- check if packet rejection has any impact on gossipsub protocol

[danwt]

@srene maybe we can close it? as it's battle tested by now? Is there still something actionable?

BTW I can say

1. do some research whether rejecting gossiped packets can be avoided when rotation for nodes syncing.

We could still cache it if it's from future height. Seems like an unnecessary optimasation. Maybe one day if we have rapid round robin rotation.

2- check if packet rejection has any impact on gossipsub protocol

It definitely 100% does because we use ValidationReject mode in libp2p which lower rep

[srene]

i dont have opinion whether to close it or not.
regarding 1 its only a limitation on caching blocks when syncing when rotation happens
2 needs to be investigated. im not sure how gossip protocol peer scoring applies to the current p2p setup. it needs to be checked

[danwt]

Makes sense
Re (2) there is an issue #1311

So we can say that this issue is specifically about accepting blocks from non proposers during rotation