Skip to content

Add fast confirmation event - #598

Merged
nflaig merged 4 commits into
ethereum:masterfrom
mkalinin:fast-confirmation-event
May 11, 2026
Merged

Add fast confirmation event#598
nflaig merged 4 commits into
ethereum:masterfrom
mkalinin:fast-confirmation-event

Conversation

@mkalinin

@mkalinin mkalinin commented Apr 20, 2026

Copy link
Copy Markdown
Contributor

Introduces fast_confirmation event 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.

- execution_payload_available
- execution_payload_bid
- payload_attestation_message
- fast_confirmation

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could add that next to the finalized_checkpoint event, but this is also fine

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this list is getting pretty big, we should sort them alphabetically maybe (can be another pr, just q for @nflaig )

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure that works too, no strong opinion, appending at the end works too, I guess the order doesn't really matter

Comment thread apis/eventstream/index.yaml Outdated

@nflaig nflaig left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@nflaig
nflaig merged commit 6934ec6 into ethereum:master May 11, 2026
3 checks passed
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 |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants