66cb18d69b
* Fix getForkSchedule call. Create cache of all configuration endpoints at node startup. Add prepareJsonResponse() call to create cached responses. Mark all procedures with `raises`. * Add getForkSchedule to VC. Fix getForkSchedule return type for API. More `raises` annotations. Fix VC fork_service.nim. * Use `push raises` instead of inline `raises`. * Improvements for REST API aggregated attestations and attestations processing. * Rename eth2_network.sendXXX procedures to eth2_network.broadcastXXX. Add broadcastBeaconBlock() and broadcastAggregateAndProof(). Fix links to specification in REST API declarations. Add implementation for v2 getStateV2(). Add validator_duties.sendXXX procedures which not only broadcast data, but also validate it. Fix JSON-RPC/REST to use new validator_duties.sendXXX procedures instead of own implementations. * Fix validator_client online nodes count incorrect value. Fix aggregate and proof attestation could be sent too late. * Adding timeout for block wait in attestations processing. Fix compilation errors. * Attempt to debug aggregate and proofs. * Fix Beacon AIP to use `sendAttestation`. Add link comment to produceBlockV2. * Add debug logs before publish operation for blocks, attestations and aggregated attestations. Fix attestations publishing issue. * logging fixes `indexInCommnittee` already logged in attestation Co-authored-by: Jacek Sieka <jacek@status.im> |
||
|---|---|---|
| .. | ||
| README.md | ||
| eth2_discovery.nim | ||
| eth2_network.nim | ||
| faststreams_backend.nim | ||
| libp2p_json_serialization.nim | ||
| libp2p_streams_backend.nim | ||
| network_metadata.nim | ||
| peer_pool.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