status-im
/
nimbus-eth2
mirror of https://github.com/status-im/nimbus-eth2.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
nimbus-eth2/docs/block_validation_flow.md

62 lines
2.2 KiB
Markdown
Raw Normal View History

Block validation flow v2 + Batch (serial) sig verification (#2250) * bump nim-blscurve * Outline the block validation flow * introduce the SigVerified types, pass the tests * Split clearance/quarantine to prepare for batch crypto verif * Add a batch signature collector * Make clearance use SigVerified block and split verification between crypto and state transition * Always use signedBeaconBlock for the onBlockAdded callback * RANDAO signing_root is the epoch instead of the full block * Support skipping BLS for testing * Fix compilation of the validator client * Try to fix strange errors MacOS and Jenkins (Clang, unknown type name br_hmac_drbg_context in stdlib_assertions.nim.c) * address https://github.com/status-im/nimbus-eth2/pull/2250#discussion_r561819858 * address https://github.com/status-im/nimbus-eth2/pull/2250#discussion_r561828025 * onBlockAdded callback should use TrustedSignedBeaconBlock https://github.com/status-im/nimbus-eth2/pull/2250#discussion_r561837261 * address https://github.com/status-im/nimbus-eth2/pull/2250#discussion_r561828946 * Use the application RNG: https://github.com/status-im/nimbus-eth2/pull/2250#discussion_r561815336 * Improve codegen of conversion zero-cost) * Quick fixes with loadWithCache after #2259 (TODO: graceful error since pubkey validations is now done first in signatures_batch) * Graceful handle rogue pubkeys and signatures now that those are lazy-loaded
2021-01-25 18:45:48 +00:00
# Block Validation Flow
This is a WIP document to explain the block validation flow.
This should be transformed into diagram that explain
the implicit block validation state machine.
## Inputs
Blocks can be received from the following sources:
- Gossipsub
- the NBC database
- a local validator block proposal
- Devtools: test suite, ncli, fuzzing
The related base types are:
- BeaconBlockBody
- BeaconBlock
- BeaconBlockBody
- + metadata (slot, blockchain state before/after, proposer)
- BeaconBlockHeader
- metadata (slot, blockchain state before/after, proposer)
- merkle hash of the BeaconBlockBody
- SignedBeaconBlock
- BeaconBlock
- + BLS signature
The base types are defined in the Eth2 specs.
On top, Nimbus builds new types to represent the level of trust and validation we have with regards to each BeaconBlock.
Those types allow the Nim compiler to help us ensure proper usage at compile-time and zero runtime cost.
### BeaconBlocks
Those are spec-defined types.
On deserialization the SSZ code guarantees that BeaconBlock are correctly max-sized
according to:
- MAX_PROPOSER_SLASHINGS
- MAX_ATTESTER_SLASHINGS
- MAX_ATTESTATIONS
- MAX_DEPOSITS
- MAX_VOLUNTARY_EXITS
### TrustedBeaconBlocks
A block that has been fully checked to be sound
both in regards to the blockchain protocol and its cryptographic signatures is known as a `TrustedBeaconBlock` or `TrustedSignedBeaconBlock`.
This allows skipping expensive signature checks.
Blocks are considered trusted if they come from:
- the NBC database
- produced by a local validator
### SigVerifiedBeaconBlocks
A block with a valid cryptographic signature is considered SigVerified.
This is a weaker guarantee than Trusted as the block might still be invalid according to the state transition function.
Such a block are produced if incoming gossip blocks' signatures are batched together for batch verification **before** being passed to state transition.
### TransitionVerifiedBeaconBlocks
A block that passes the state transition checks and can be successfully applied to the beacon chain is considered `TransitionVerified`.
Such a block can be produced if incoming blocks' signatures are batched together for batch verification **after** successfully passing state transition.