nimbus-eth2/beacon_chain/consensus_object_pools
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 Consensus object pools [reorg 4/5] (#2374) 2021-03-04 10:13:44 +01:00
attestation_pool.nim remove attestation/aggregate queue (#2519) 2021-04-26 22:39:44 +02:00
block_clearance.nim add attestation stats tool to ncli_db (#2539) 2021-05-07 13:36:21 +02:00
block_pools_types.nim Revamp attestation pool 2021-04-13 20:24:02 +03:00
block_quarantine.nim Consensus object pools [reorg 4/5] (#2374) 2021-03-04 10:13:44 +01:00
blockchain_dag.nim add attestation stats tool to ncli_db (#2539) 2021-05-07 13:36:21 +02:00
exit_pool.nim remove some BeaconState use and abstract over other uses (#2482) 2021-04-08 08:24:25 +00:00
spec_cache.nim Perform attestation check before broadcast (#2550) 2021-05-10 09:13:36 +02:00
statedata_helpers.nim more abstraction over BeaconState (#2509) 2021-04-16 08:49:37 +00:00

README.md

Consensus object pools

This folder holds the various consensus object pools needed for a blockchain client.

Object in those pools have passed the "gossip validation" filter according to specs:

After "gossip validation" the consensus objects can be rebroadcasted as they are optimistically good, however for internal processing further verification is needed. For blocks, this means verifying state transition and all contained cryptographic signatures (instead of just the proposer signature). For other consensus objects, it is possible that gossip validation is a superset of consensus verification (TODO).

The pools presenet in this folder are:

  • block_pools:
    • block_quarantine: for seemingly valid blocks that are on a fork unknown to us.
    • block_clearance: to verify (state_transition + cryptography) candidate blocks.
    • blockchain_dag: an in-memory direct-acyclic graph of fully validated and verified blockchain candidates with the tail being the last finalized epoch. A block in the DAG MUST be in the fork choice and a block in the fork choice MUST be in the DAG (except for orphans following finalization). On finalization non-empty epoch blocks are stored in the beacon_chain_db.
  • attestation_pool: Handles the attestation received from gossip and collect them for fork choice.
  • exit_pool: Handle voluntary exits and forced exits (attester slashings and proposer slashings)