nimbus-eth2/beacon_chain/gossip_processing
Mamy Ratsimbazafy 6b13cdce36
Batch attestations (#2439)
* batch attestations

* Fixes (but now need to investigate the chronos 0 .. 4095 crash similar to https://github.com/status-im/nimbus-eth2/issues/1518

* Try to remove the processing loop to no avail :/

* batch aggregates

* use resultsBuffer size for triggering deadline schedule

* pass attestation pool tests

* Introduce async gossip validators. May fix the 4096 bug (reentrancy issue?) (similar to sync unknown blocks #1518)

* Put logging at debug level, add speed info

* remove unnecessary batch info when it is known to be one

* downgrade some logs to trace level

* better comments [skip ci]

* Address most review comments

* only use ref for async proc

* fix exceptions in eth2_network

* update async exceptions in gossip_validation

* eth2_network 2nd pass

* change to sleepAsync

* Update beacon_chain/gossip_processing/batch_validation.nim

Co-authored-by: Jacek Sieka <jacek@status.im>

Co-authored-by: Jacek Sieka <jacek@status.im>
2021-04-02 16:36:43 +02:00
..
README.md Reorg (5/5) (#2377) 2021-03-05 14:12:00 +01:00
batch_validation.nim Batch attestations (#2439) 2021-04-02 16:36:43 +02:00
consensus_manager.nim add metric for nextActionWait (#2399) 2021-03-12 09:46:26 +00:00
eth2_processor.nim Batch attestations (#2439) 2021-04-02 16:36:43 +02:00
gossip_to_consensus.nim Batch attestations (#2439) 2021-04-02 16:36:43 +02:00
gossip_validation.nim Batch attestations (#2439) 2021-04-02 16:36:43 +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.

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