increase after-block attestation delay (#3518)

Recently, block processing times have been going up as the network grows
making early attestation riskier. Since blocks are big and attestations
are small (though numerous and therefore bandwidth-intense), it seems
better to wait a little bit longer after receiving a block, before we
publish the attestation.

beacon_chain/validators/validator_duties.nim

@@ -1111,18 +1111,19 @@ proc handleValidatorDuties*(node: BeaconNode, lastSlot, slot: Slot) {.async.} =
       # An opposite case is that we received (or produced) a block that has
       # not yet reached our neighbours. To protect against our attestations
       # being dropped (because the others have not yet seen the block), we'll
-      # impose a minimum delay of 1000ms. The delay is enforced only when we're
+      # impose a minimum delay of 2000ms. The delay is enforced only when we're
       # not hitting the "normal" cutoff time for sending out attestations.
       # An earlier delay of 250ms has proven to be not enough, increasing the
-      # risk of losing attestations.
+      # risk of losing attestations, and with growing block sizes, 1000ms
+      # started to be risky as well.
       # Regardless, because we "just" received the block, we'll impose the
       # delay.
 
-      const afterBlockDelay = 1000
+      const afterBlockDelay = millis(2000)
       let
-        afterBlockTime = node.beaconClock.now() + millis(afterBlockDelay)
+        afterBlockTime = node.beaconClock.now() + afterBlockDelay
         afterBlockCutoff = node.beaconClock.fromNow(
-          min(afterBlockTime, slot.attestation_deadline() + millis(afterBlockDelay)))
+          min(afterBlockTime, slot.attestation_deadline() + afterBlockDelay))
 
       if afterBlockCutoff.inFuture:
         debug "Got block, waiting to send attestations",