document and temporary workaround for extended validation issue

beacon_chain/block_pool.nim

@@ -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 =