23eea197f6
* Implement split preset/config support This is the initial bulk refactor to introduce runtime config values in a number of places, somewhat replacing the existing mechanism of loading network metadata. It still needs more work, this is the initial refactor that introduces runtime configuration in some of the places that need it. The PR changes the way presets and constants work, to match the spec. In particular, a "preset" now refers to the compile-time configuration while a "cfg" or "RuntimeConfig" is the dynamic part. A single binary can support either mainnet or minimal, but not both. Support for other presets has been removed completely (can be readded, in case there's need). There's a number of outstanding tasks: * `SECONDS_PER_SLOT` still needs fixing * loading custom runtime configs needs redoing * checking constants against YAML file * yeerongpilly support `build/nimbus_beacon_node --network=yeerongpilly --discv5:no --log-level=DEBUG` * load fork epoch from config * fix fork digest sent in status * nicer error string for request failures * fix tools * one more * fixup * fixup * fixup * use "standard" network definition folder in local testnet Files are loaded from their standard locations, including genesis etc, to conform to the format used in the `eth2-networks` repo. * fix launch scripts, allow unknown config values * fix base config of rest test * cleanups * bundle mainnet config using common loader * fix spec links and names * only include supported preset in binary * drop yeerongpilly, add altair-devnet-0, support boot_enr.yaml |
||
---|---|---|
.. | ||
README.md | ||
batch_validation.nim | ||
block_processor.nim | ||
consensus_manager.nim | ||
eth2_processor.nim | ||
gossip_validation.nim |
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)
- method
- a
xyzValidator
message enqueues the validated object in one of the processing queue in eth2_processorblocksQueue: 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