nimbus-eth2/beacon_chain/networking
zah 0f758c5f02
Working Makefile targets for Capella devnet2 (#4494)
* Working Makefile targets for Capella devnet2

make capella-devnet-2
make clean-capella-devnet-2

You'll need to have https://github.com/tmuxinator/tmuxinator installed.
It's available as a regular package in most Linux distributions or through
Nix or Brew on macOS.

This commit also fixes the initial hang in the Eth1 monitor in the "find
TTD block" procedure through a fix to the network metadata files which
hasn't been upstreamed yet.

Other changes:

* Disabled Geth snap sync in the simulation

When all Geth nodes are configured to run with snap sync enabled, they all
start snap sync after the first forkchoiceUpdated which causes the BNs to
skip validator duties because the EL is syncing. The snap sync never completes
due to poor connectivity between the Geth nodes in the simulation.
2023-01-13 12:21:58 +02:00
..
README.md Reorg (5/5) (#2377) 2021-03-05 14:12:00 +01:00
eth2_discovery.nim compatibility with Nim 1.4+ (#3888) 2022-07-29 10:53:42 +00:00
eth2_network.nim Gnosis const preset 2023-01-13 04:28:29 +02:00
libp2p_json_serialization.nim compatibility with Nim 1.4+ (#3888) 2022-07-29 10:53:42 +00:00
network_metadata.nim Working Makefile targets for Capella devnet2 (#4494) 2023-01-13 12:21:58 +02:00
peer_pool.nim compatibility with Nim 1.4+ (#3888) 2022-07-29 10:53:42 +00:00
peer_scores.nim rename `PeerScoreXyzBlocks` -> `PeerScoreXyzValues` (#4318) 2022-11-11 11:34:28 +00:00
topic_params.nim reduce LC optsync latency (#4002) 2022-08-25 03:53:59 +00:00

README.md

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