1ef7d237cc
This PR allows sharing the pubkey data between validators by using a thread-local cache for pubkey data, netting about a 400mb mem usage reduction on holesky due to us keeping 3 permanent + several ephemeral state copies in memory at all times and each state copy holding a full validator. The PR also introduces a hash cache for the key which gives ~14% speedup for a full state `hash_tree_root` - the key makes up for a large part of the `Validator` htr time. Finally, the time it takes to copy a state goes down as well from ~80m ms to ~60, for reasons similar to htr. We use a `ptr` even if a `ref` could in theory have been used - there is not much practical benefit to a `ref` (given it's mutable) while a `ptr` is cheaper and easier to copy (when copying temporary states). We could go further and cache a cooked pubkey but it turns out this is quite intrusive - in all the relevant places, we're already using a cooked key from the immutable validator data so there are no immediate performance gains of doing so while managing the compressed -> cooked key mapping would become more difficult - something for a future PR perhaps. Co-authored-by: Etan Kissling <etan@status.im> |
||
|---|---|---|
| .. | ||
| README.md | ||
| eth2_discovery.nim | ||
| eth2_network.nim | ||
| eth2_protocol_dsl.nim | ||
| libp2p_json_serialization.nim | ||
| network_metadata.nim | ||
| network_metadata_downloads.nim | ||
| network_metadata_gnosis.S | ||
| network_metadata_mainnet.S | ||
| peer_pool.nim | ||
| peer_protocol.nim | ||
| peer_scores.nim | ||
| topic_params.nim | ||
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