History

tersec 79bb0d5379 only deserialize attestation and aggregation gossiped signatures once (#2472 ) * only deserialize attestation and aggregation gossiped signatures once * re-indent some aggregate checks into block scope * spelling * remove debugging assertion * put part of gossip validation back into block context * attestation pool test signature loading isn't so unsafe, and exportRaw isn't free * remove more development doAsserts; don't exportRaw in loops		2021-04-09 14:59:24 +02:00
..
README.md	Reorg (5/5) (#2377 )	2021-03-05 14:12:00 +01:00
batch_validation.nim	only deserialize attestation and aggregation gossiped signatures once (#2472 )	2021-04-09 14:59:24 +02:00
consensus_manager.nim	add metric for nextActionWait (#2399 )	2021-03-12 09:46:26 +00:00
eth2_processor.nim	only deserialize attestation and aggregation gossiped signatures once (#2472 )	2021-04-09 14:59:24 +02:00
gossip_to_consensus.nim	only deserialize attestation and aggregation gossiped signatures once (#2472 )	2021-04-09 14:59:24 +02:00
gossip_validation.nim	only deserialize attestation and aggregation gossiped signatures once (#2472 )	2021-04-09 14:59:24 +02:00

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.

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.

As the first line of defense in Nimbus, modules must be able to handle burst of data that may come: