Verify blocks before storing them as pending #545

Activity

1. Aliemeka commented on Sep 7, 2026

   

   Aliemeka

   on Sep 7, 2026

   Contributor

   More actions

   Will love to take a look into this @MegaRedHand
2. MegaRedHand commented on Sep 7, 2026

   

   MegaRedHand

   on Sep 7, 2026

   CollaboratorAuthor

   More actions

   Sure, but I suggest coming up with a list of checks to do before opening a PR
3. MegaRedHand

   assigned

   Aliemeka

   on Sep 7, 2026
4. Aliemeka commented on Sep 8, 2026

   

   Aliemeka

   on Sep 8, 2026

   Contributor

   More actions

   Ok
5. Aliemeka commented on Sep 8, 2026

   

   Aliemeka

   on Sep 8, 2026

   Last edited by Aliemeka

   Contributor

   More actions

   @MegaRedHand here a list of items I think we should be checking for:

   1. First, check if the propose block matches the slot, is_proposer(proposer_index, slot, num_validators), using the finalized state's validator count.
   2. Check if any entry has duplicate AttestationData in the block.body.attestations list so we don't count more than once.
   3. Also ensure that distinct attestation does not exceed the MAX_ATTESTATIONS_DATA cap, reject blocks that exceed the cap.
   4. Ensure proposer_index and every validator index set in each attestation's aggregation_bits are below the validator count. An index at or above it names a validator that does not exist, so the block can't be valid.
   5. A parent root sanity check to ensure the the parent_root is not equal to the block's root or the zero root.
   6. If the parent header is already in the DB as an earlier pending block, require block.slot > parent.slot.
   7. Reject blocks which parent is on a finalized-conflicting fork and is not the finalized root.
   8. Reject if parent_root is in a set of roots that previously failed the state transition.
   9. Also skip, if header for the parent_root exists.
   10. Cap how many pending blocks the node keeps in total and per slot, evicting the oldest when full, so a flood of unimportable blocks cannot grow memory and disk without bound.
   11. Finally, verifying signature as stated by you using verify_block_signatures(&finalized_state, &signed_block) so forged blocks don't make it through.

   Also can some additional clean up be done like:

   1. Deleting DB rows on discard discard_pending_subtree
   2. Drop pending storage for BlocksByRange blocks whose parent is missing, since they arrive in order and a gap means a bad peer, while still pending gossip and BlocksByRoot blocks.
6. Aliemeka commented on Sep 8, 2026

   

   Aliemeka

   on Sep 8, 2026

   Contributor

   More actions

   @MegaRedHand here a list of items I think we should be checking for:

   1. First, check if the propose block matches the slot, is_proposer(proposer_index, slot, num_validators), using the finalized state's validator count.
   2. Check if any entry has duplicate AttestationData in the block.body.attestations list so we don't count more than once.
   3. Also ensure that distinct attestation does not exceed the MAX_ATTESTATIONS_DATA cap, reject blocks that exceed the cap.
   4. Ensure proposer_index and every validator index set in each attestation's aggregation_bits are below the validator count. An index at or above it names a validator that does not exist, so the block can't be valid.
   5. A parent root sanity check to ensure the the parent_root is not equal to the block's root or the zero root.
   6. If the parent header is already in the DB as an earlier pending block, require block.slot > parent.slot.
   7. Reject blocks which parent is on a finalized-conflicting fork and is not the finalized root.
   8. Reject if parent_root is in a set of roots that previously failed the state transition.
   9. Also skip, if header for the parent_root exists.
   10. Cap how many pending blocks the node keeps in total and per slot, evicting the oldest when full, so a flood of unimportable blocks cannot grow memory and disk without bound.
   11. Finally, verifying signature as stated by you using verify_block_signatures(&finalized_state, &signed_block) so forged blocks don't make it through.

   Also can some additional clean up be done like:

   1. Deleting DB rows on discard discard_pending_subtree
   2. Drop pending storage for BlocksByRange blocks whose parent is missing, since they arrive in order and a gap means a bad peer, while still pending gossip and BlocksByRoot blocks.

   Please let me know what your thoughts on these @MegaRedHand
7. MegaRedHand commented on Sep 9, 2026

   

   MegaRedHand

   on Sep 9, 2026

   CollaboratorAuthor

   More actions

   9. Also skip, if header for the parent_root exists.

   Not sure about this one.

   10. Cap how many pending blocks the node keeps in total and per slot

   I would leave this one for a following PR. Same for the additional clean up of the DB and pending blocks.

   The rest of the list looks good.

   👍React with 👍1Reacted by Emeka Allison