Add fast confirmation event - #598
Merged
Merged
Conversation
nflaig
reviewed
Apr 20, 2026
| - execution_payload_available | ||
| - execution_payload_bid | ||
| - payload_attestation_message | ||
| - fast_confirmation |
Member
There was a problem hiding this comment.
we could add that next to the finalized_checkpoint event, but this is also fine
Contributor
There was a problem hiding this comment.
this list is getting pretty big, we should sort them alphabetically maybe (can be another pr, just q for @nflaig )
Member
There was a problem hiding this comment.
sure that works too, no strong opinion, appending at the end works too, I guess the order doesn't really matter
nflaig
reviewed
Apr 20, 2026
This was referenced May 13, 2026
tersec
pushed a commit
to status-im/nimbus-eth2
that referenced
this pull request
May 20, 2026
nazarhussain
added a commit
to ChainSafe/lodestar
that referenced
this pull request
Jun 8, 2026
Adds the standardized fast_confirmation server-sent event topic for the Fast Confirmation Rule. The event fires once per FCR execution and carries `block`, `slot`, and `current_slot`. Skips matching against the published oapi schema for now since the spec release with `current_slot` has not landed yet (ethereum/beacon-APIs#598). The Lodestar-private /eth/v1/lodestar/fast_confirmation endpoint stays available for adhoc debugging.
nflaig
pushed a commit
to ChainSafe/lodestar
that referenced
this pull request
Jun 9, 2026
- Wires the new `fast_confirmation` Server-Sent Event from beacon-APIs PR [#598](ethereum/beacon-APIs#598). The event fires once per slot whenever the Fast Confirmation Rule executes and carries `{block, slot}`, where `slot` is the slot of the confirmed beacon block. - Crosses the fork-choice ↔ beacon-node boundary via a new optional `onFastConfirmation` callback on `ForkChoiceStore`, mirroring the existing `onJustified` / `onFinalized` plumbing. The emit is invoked from `ForkChoice.runFastConfirmation()` after the rule succeeds. - Removes the now-redundant Lodestar-namespace endpoint `GET /eth/v1/lodestar/fast_confirmation_info` (and its `getConfirmedBlock` helper) — the standard SSE event supersedes it, and the head/checkpoint fields it bundled are already available via standard beacon-API endpoints. This PR is aligned with the changes proposed in ethereum/beacon-APIs#616 ### Architecture ``` Chain.onClockSlot → forkChoice.updateTime └── (per tick) runFastConfirmation └── fcStore.notifyFastConfirmation({block, slot}) └── ChainEventEmitter.emit(EventType.fastConfirmation, {block, slot}) └── SSE subscribers via /eth/v1/events?topics=fast_confirmation ``` `ApiEvents` in `ChainEventEmitter` is derived from `routes.events.EventType`, so adding the new variant flows through automatically — no per-event boilerplate in the chain or events API layers. ### Edge cases | Scenario | Behavior | |---|---| | `--chain.fastConfirmation` disabled (default) | No emit (FCR doesn't run) | | FCR rule throws | No emit; existing warn-and-continue catch is unchanged | | Confirmed root not in `protoArray` (defensive) | Warn log with `slot`+`confirmedRoot`, skip emit | | `updateTime` advances multiple slots | One emit per tick |
This file contains hidden or 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
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.
Introduces
fast_confirmationevent with the following fields:block: A beacon block root output by the Fast confirmation rule.slot: A slot of the confirmed beacon block.This event is supposed to be triggered after each execution of the Fast confirmation rule which should happen once per slot.
Fast confirmation rule is an algorithm that runs on top of the beacon chain consensus protocol and outputs a beacon block that won’t be reorged if network synchrony and adversarial threshold assumptions hold. Introduced by ethereum/consensus-specs#4747
Rationale
Fast confirmed block is a property of the beacon chain consensus protocol similar to finalized block and head which might be useful for consumers of the beacon chain data e.g. L2s. For JSON-RPC API consumers there is a “safe” block tag that denotes block hash of the most recent confirmed payload.