History

Jacek Sieka 867d8f3223 Perform attestation check before broadcast (#2550 ) Currently, we have a bit of a convoluted flow where when sending attestations, we start broadcasting them over gossip then pass them to the attestation validation to include them in the local attestation pool - it should be the other way around: we should be checking attestations _before_ gossipping them - this serves as an additional safety net to ensure that we don't publish junk - this becomes more important when publishing attestations from the API. Also, the REST API was performing its own validation meaning attestations coming from REST would be validated twice - finally, the JSON RPC wasn't pre-validating and would happily broadcast invalid attestations. * Unified attestation production pipeline with the same flow for gossip, locally and API-produced attestations: all are now validated and entered into the pool, then broadcast/republished * Refactor subnet handling with specific SubnetId alias, streamlining where subnets are computed, avoiding the need to pass around the number of active validators * Move some of the subnet handling code to eth2_network * Use BitArray throughout for subnet handling		2021-05-10 09:13:36 +02:00
..
README.md	Reorg (5/5) (#2377 )	2021-03-05 14:12:00 +01:00
batch_validation.nim	remove attestation/aggregate queue (#2519 )	2021-04-26 22:39:44 +02:00
consensus_manager.nim	add metric for nextActionWait (#2399 )	2021-03-12 09:46:26 +00:00
eth2_processor.nim	Perform attestation check before broadcast (#2550 )	2021-05-10 09:13:36 +02:00
gossip_to_consensus.nim	remove attestation/aggregate queue (#2519 )	2021-04-26 22:39:44 +02:00
gossip_validation.nim	Perform attestation check before broadcast (#2550 )	2021-05-10 09:13:36 +02:00

README.md

Gossip Processing

This folders hold a collection of modules to:

validate raw gossip data before
- rebroadcasting them (potentially aggregated)
- sending it to one of the consensus object pool

Validation

Gossip Validation is different from consensus verification in particular for blocks.

Blocks: https://github.com/ethereum/eth2.0-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#beacon_block
Attestations (aggregate): https://github.com/ethereum/eth2.0-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#beacon_aggregate_and_proof
Attestations (single): https://github.com/ethereum/eth2.0-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#attestation-subnets
Exits: https://github.com/ethereum/eth2.0-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#voluntary_exit
Proposer slashings: https://github.com/ethereum/eth2.0-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#proposer_slashing
Attester slashing: https://github.com/ethereum/eth2.0-specs/blob/v1.0.1/specs/phase0/p2p-interface.md#attester_slashing

There are 2 consumers of validated consensus objects:

a ValidationResult.Accept output triggers rebroadcasting in libp2p
- method validate(PubSub, message) in libp2p/protocols/pubsub/pubsub.nim in the
- which was called by rpcHandler(GossipSub, PubSubPeer, RPCMsg)
a xyzValidator message enqueues the validated object in one of the processing queue in eth2_processor
- blocksQueue: AsyncQueue[BlockEntry], (shared with request_manager and sync_manager)
- attestationsQueue: AsyncQueue[AttestationEntry]
- aggregatesQueue: AsyncQueue[AggregateEntry]

Those queues are then regularly processed to be made available to the consensus object pools.

Security concerns

As the first line of defense in Nimbus, modules must be able 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