When a late block arrives and the beacon is proposing the next block, we
perform several checks to allow for the next block to reorg the incoming
late block.
Among those checks, we check that the parent block has been heavily
attested (currently 160% of the committee size).
We perform this check in these circumstances:
- When the late block arrives
- At 10 seconds into the slot
- At 0 seconds into the next slot (at proposing time)
The problem is that for blocks that arrive between 4 seconds and 10
seconds, the parent block will not have yet this expected weight since
attestations from the current committee were not imported yet, and thus
Prysm will send an FCU with payload attributes anyway at this time.
What happens is that Prysm keeps the EL building different blocks based
on different parents at the same time, when later in the next slot it
calls to propose, it will reorg the late block anyway and the EL would
have been computing a second payload uselessly.
This PR enables this check only when calling `ShouldOverrideFCU` after
10 seconds into the slot which we do only after having imported the
current attestations. We may want to actually remove this check entirely
from `ShouldOverrideFCU` and only keep it in `ProposerHead`.
Shout out to Anthithesis for reporting an issue that led to this
discoverly.
* First take at updating everything to v5
* Patch gRPC gateway to use prysm v5
Fix patch
* Update go ssz
---------
Co-authored-by: Preston Van Loon <pvanloon@offchainlabs.com>
* Check init sync before getting payload attributes
This PR adds a helper to forkchoice to return the delay of the latest
imported block. It also adds a helper with an heuristic to check if the
node is during init sync. If the highest imported node was imported with
a delay of less than an epoch then the node is considered in regular
sync. If on the other hand, in addition the highest imported node is
more than two epochs old, then the node is considered in init Sync.
The helper to check this only uses forkchoice and therefore requires a
read lock. There are four paths to call this
1) During regular block processing, we defer a function to send the
second FCU call with attributes. This function may not be called at
all if we are not regularly syncing
2) During regular block processing, we check in the path
`postBlockProces->getFCUArgs->computePayloadAttributes` the payload
attributes if we are syncing a late block. In this case forkchoice is
already locked and we add a call in `getFCUArgs` to return early if not
regularly syncing
3) During handling of late blocks on `lateBlockTasks` we simply return
early if not in regular sync (This is the biggest change as it takes
a longer FC lock for lateBlockTasks)
4) On Attestation processing, in UpdateHead, we are already locked so we
just add a check to not update head on this path if not regularly
syncing.
* fix build
* Fix mocks
* forkchoice.Getter wrapper with locking wrappers
* comments
* lint
* only expose fast fc getters
* potuz feedback re rlock
* update mocks for new fc method
* appease deepsource
* add missing exported func comment
* yeet errors to make the linter happy
* even more devious _discard
* rm TargetRoot
* derp
* handle nil error in _discard
* deep source
---------
Co-authored-by: Kasey Kirkham <kasey@users.noreply.github.com>
Co-authored-by: prylabs-bulldozer[bot] <58059840+prylabs-bulldozer[bot]@users.noreply.github.com>
* With attribute, use justified hash as safe block hash
* Use UnrealizedJustifiedPayloadBlockHash
* Cleanups
* Add test to forkchoice
* Block proposal
* Fix mock
* Fix test
* Fix rest of the tests
* Potuz feedback
* Fix test
* Use unrealized justified hash for regular fcu
* forkchoice changes
* gazelle
* remove best justified from forkchoice dump
* keep protobufs and update comment
* remove phase0 tests
* bumb spectests version
* missing sha
* Fix sha256 for spec
* rpc tests
* Mark field 3 as reserved so it will never be used it again
---------
Co-authored-by: terence tsao <terence@prysmaticlabs.com>
Co-authored-by: Preston Van Loon <preston@prysmaticlabs.com>
* write locks
* fix forkchoice tests
* blockchain locks
* lock on IsOptimistic
* use forkchoice instead of chaininfo within savehead
* Use forkchoice HasNode to check if a block is consistent with finality
* interface fix
* Use forkchoice HasNode to check if a block is consistent with finality
* interface fix
* fix tests
* remove VerifyFinalizedBlkDescendant
* don't write lock wrappers
* fix validateBeaconBlock
* Terence's review and more missing locks
* add lock for InForkChoice
* lock head on fillMissingBlockPayload
* fix lock on IsOptimisticForRoot
* fix lock in fillMissingBlockPayloadId
* extra comments
* lock proposerBoost on spectests
* nishant's review
---------
Co-authored-by: Nishant Das <nishdas93@gmail.com>
* Implement should_override_forchoice_update
* add tests
* remove unused exported function
* go mod tidy
* fix go mod
* Fix go mod tidy
* Fix context import
* mod tidy
* fix test
* Terence's review
* fix test
---------
Co-authored-by: terence tsao <terence@prysmaticlabs.com>
* Aditya's PR 18
This PR implements PR18. There is still a missing piece which is
consistency of head with finalized checkpoint. I will think on ways to
enforce this.
* prune finalized incompatible
* don't check finalization on viable for head
* unit tests fixes
* gazelle
* remove finalized epoch from viableForHead
* remove finalized epoch from leadsToViableHead
* use non-slashed indices
* function rename
* lint fixes
* lint fixes
* lint fixes
* delete from s.nodeByPayload as well when pruneFinalizedNodeByRootMap
* regresstion test
* add different payload node
---------
Co-authored-by: Raul Jordan <raul@prysmaticlabs.com>
Co-authored-by: Radosław Kapka <rkapka@wp.pl>
* Update go to 1.19.3
* Update other items to 1.19
* Update golangci-lint to latest release
* Run gofmt -s with go1.19
* Huge gofmt changes
Co-authored-by: Raul Jordan <raul@prysmaticlabs.com>
* init
* unit test
* DeepSource complains
* gaz
* shutting deepsource down
* change var name and use handler type
* Kasey's name suggestion
* fix stategen
* interface signature
Co-authored-by: terencechain <terence@prysmaticlabs.com>
