mirror of
https://github.com/status-im/nimbus-eth2.git
synced 2025-01-09 05:52:45 +00:00
d028baea2a
On `ELECTRA_FORK_EPOCH`, PeerDAS is not yet activated, hence the current mechanism based on `BlobSidecar` is still in use. With EIP-7688, the generalized indices of `BeaconBlockBody` get reindexed, changing the length of the inclusion proof within the `BlobSidecar`. Because network Req/Resp operations allow responses across fork boundaries, this creates the need for a `ForkedBlobSidecar` in that layer, same as already done for `ForkedSignedBeaconBock` for similar reasons. Note: This PR is only needed if PeerDAS is adopted _after_ EIP-7688. If PeerDAS is adopted _before_ EIP-7688, a similar PR may be needed for forked columns. Coincidental `Forked` jank can only be fully avoided if both features activate at the same epoch, actual changes to blobs aside. Delaying EIP-7688 for sole purpose of epoch alignemnt is not worth it.
Networking
This folders hold a collection of modules to:
- configure the Eth2 P2P network
- discover, connect, and maintain quality Eth2 peers
Data received is handed other to the ../gossip_processing modules for validation.
Security concerns
- Collusion: part of the peer selection must be kept random. This avoids peers bringing all their friends and colluding against a beacon node.
- Denial-of-service: The beacon node must provide ways to handle burst of data that may come:
- from malicious nodes trying to DOS us
- from long periods of non-finality, creating lots of forks, attestations, forks