document and temporary workaround for extended validation issue

This commit is contained in:
Dustin Brody 2020-04-03 19:49:46 +02:00 committed by tersec
parent d180724d41
commit f9e45dc121
1 changed files with 38 additions and 3 deletions

View File

@ -982,6 +982,16 @@ proc isValidBeaconBlock*(pool: BlockPool,
debug "isValidBeaconBlock: block is not from a slot greater than the latest finalized slot"
return false
# The proposer signature, signed_beacon_block.signature, is valid with
# respect to the proposer_index pubkey.
# TODO resolve following two checks' robustness and remove this early exit.
const alwaysTrue = true
if alwaysTrue:
return true
# TODO because this check depends on the proposer aspect, and see the comment
# there for that issue, the fallout is this check isn't reliable anymore.
# The block is the first block with valid signature received for the proposer
# for the slot, signed_beacon_block.message.slot.
#
@ -1019,9 +1029,6 @@ proc isValidBeaconBlock*(pool: BlockPool,
return false
# The proposer signature, signed_beacon_block.signature, is valid with
# respect to the proposer_index pubkey.
# If this block doesn't have a parent we know about, we can't/don't really
# trace it back to a known-good state/checkpoint to verify its prevenance;
# while one could getOrResolve to queue up searching for missing parent it
@ -1029,6 +1036,34 @@ proc isValidBeaconBlock*(pool: BlockPool,
# answering yes/no, not queuing other action or otherwise altering state.
let parent_ref = pool.getRef(signed_beacon_block.message.parent_root)
if parent_ref.isNil:
# TODO find where incorrect block's being produced at/around epoch 20,
# nim-beacon-chain commit 708ac80daef5e05e01d4fc84576f8692adc256a3, at
# 2020-04-02, running `make eth2_network_simulation`, or, alternately,
# why correctly produced ancestor block isn't found. By appearances, a
# chain is being forked, probably by node 0, as nodes 1/2/3 die first,
# then node 0 only dies eventually then nodes 1/2/3 are not around, to
# help it in turn finalize. So node 0 is probably culprit, around/near
# the end of epoch 19, in its block proposal(s). BlockPool.add() later
# discovers this same missing parent. The missing step here is that we
# need to be able to receive this block and store it in unresolved but
# without passing it on to other nodes (which is what EV actually does
# specify). The other BeaconBlock validation conditions cannot change,
# just because later blocks fill in gaps, but this one can. My read of
# the intent here is that only nodes which know about the parentage of
# a block should pass it on. That doesn't mean we shouldn't process it
# though, just not rebroadcast it.
# Debug output: isValidBeaconBlock: incorrectly skipping BLS validation when parent block unknown topics="blkpool" tid=2111475 file=block_pool.nim:1040 current_epoch=22 current_slot=133 parent_root=72b5b0f1 pool_head_slot=131 pool_head_state_root=48e9f4b8 proposed_block_slot=133 proposed_block_state_root=ed7b1ddd proposer_index=42 node=3
# So it's missing a head update, probably, at slot 132.
debug "isValidBeaconBlock: incorrectly skipping BLS validation when parent block unknown",
current_slot = current_slot,
current_epoch = compute_epoch_at_slot(current_slot),
parent_root = signed_beacon_block.message.parent_root,
proposed_block_slot = signed_beacon_block.message.slot,
proposer_index = signed_beacon_block.message.proposer_index,
proposed_block_state_root = signed_beacon_block.message.state_root,
pool_head_slot = pool.headState.data.data.slot,
pool_head_state_root = pool.headState.data.root
return false
let bs =