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

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.
This commit is contained in:
Jacek Sieka 2022-03-18 12:02:32 +01:00 committed by GitHub
parent 12dc427535
commit 8395f7de8c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
beacon_chain/validators/validator_duties.nim
View File

@ -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 # An opposite case is that we received (or produced) a block that has
# not yet reached our neighbours. To protect against our attestations # not yet reached our neighbours. To protect against our attestations
# being dropped (because the others have not yet seen the block), we'll # 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. # not hitting the "normal" cutoff time for sending out attestations.
# An earlier delay of 250ms has proven to be not enough, increasing the # 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 # Regardless, because we "just" received the block, we'll impose the
# delay. # delay.
const afterBlockDelay = 1000 const afterBlockDelay = millis(2000)
let let
afterBlockTime = node.beaconClock.now() + millis(afterBlockDelay) afterBlockTime = node.beaconClock.now() + afterBlockDelay
afterBlockCutoff = node.beaconClock.fromNow( afterBlockCutoff = node.beaconClock.fromNow(
min(afterBlockTime, slot.attestation_deadline() + millis(afterBlockDelay))) min(afterBlockTime, slot.attestation_deadline() + afterBlockDelay))
if afterBlockCutoff.inFuture: if afterBlockCutoff.inFuture:
debug "Got block, waiting to send attestations", debug "Got block, waiting to send attestations",