Review importBlock order of operations #4976
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dapplion
commented
Jan 5, 2023
| @@ -309,7 +309,7 @@ export class ForkChoice implements IForkChoice { | |||
| blockDelaySec: number, | |||
| currentSlot: Slot, | |||
| executionStatus: MaybeValidExecutionStatus | |||
| ): void { | |||
| ): ProtoBlock { | |||
There was a problem hiding this comment.
Make onBlock return the blockSummary to prevent having to consider in the forkchoice that the new block is not found in the fork-choice
dapplion
commented
Jan 5, 2023
| import {REPROCESS_MIN_TIME_TO_NEXT_SLOT_SEC} from "../reprocess.js"; | ||
| import {RegenCaller} from "../regen/interface.js"; | ||
| import type {BeaconChain} from "../chain.js"; | ||
| import {BlockInputType, FullyVerifiedBlock, ImportBlockOpts, AttestationImportOpt} from "./types.js"; | ||
| import {PendingEvents} from "./utils/pendingEvents.js"; |
There was a problem hiding this comment.
- From Remove all intermediary ChainEvents #4973 all remaining events are safe to be emitted in the order of this PR
There was a problem hiding this comment.
it may be safe from a logic perspective, but we may want to keep this to avoid a future footgun?
Now we will be adding additional work, running all event handlers, interspersed with importBlock, which we want to finish ASAP.
There was a problem hiding this comment.
It's safe because none of those events trigger side effects, unlike they did before. They are solely consumed by API eventsream clients
dapplion
force-pushed
the
dapplion/importblock-order
branch
from
fb549ae to
84b4cdb
Compare
Performance Report✔️ no performance regression detected Full benchmark results
|
The only If there are not awaits it's more of a question of what is allowed to throw before what. Regarding the head state keep in mind there's a possibility the head state is not available, so it triggers regen and will be null for a while. |
dapplion
force-pushed
the
dapplion/importblock-order
branch
from
84b4cdb to
a565018
Compare
|
Closing + re-opening to trigger CI, somehow it got stuck |
wemeetagain
approved these changes
Jan 5, 2023
g11tech
reviewed
Jan 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
We noted with @g11tech that the import order of importBlock is not safe since it can import a block into the fork-choice without it being available in the DB. That can cause the node to get stuck if it ever needs to regen, and other potential undefined behavior.
Description
ImportBlock order of operations must guarantee that BeaconNode does not end in an unknown state:
in the DB. Otherwise the beacon node may end up in an unrecoverable state. If a block is persisted in the hot
db but is unknown by the fork-choice, then it will just use some extra disk space. On restart is will be
pruned regardless.
write happens latter requires the ability to roll back a fork-choice head change if disk write fails