Fast Confirmation Rule - #4747
Merged
Merged
Conversation
tersec
pushed a commit
to status-im/nimbus-eth2
that referenced
this pull request
Apr 13, 2026
get_safe_beacon_block_root was renamed to retrieve_fast_confirmed_root in the specs: - ethereum/consensus-specs#4747
etan-status
reviewed
Apr 14, 2026
jtraglia
reviewed
Apr 15, 2026
jtraglia
reviewed
Apr 15, 2026
0xMushow
approved these changes
Apr 15, 2026
0xMushow
left a comment
0xMushow
left a comment
Contributor
There was a problem hiding this comment.
LGTM. Left a couple more nits, and inconsistencies in using !=, ==, vs is not and is in .py file.
0xMushow
reviewed
Apr 15, 2026
Co-authored-by: 0xMushow <105550256+0xMushow@users.noreply.github.com>
jtraglia
reviewed
Apr 15, 2026
jtraglia
approved these changes
Apr 15, 2026
jtraglia
left a comment
jtraglia
left a comment
Member
There was a problem hiding this comment.
LGTM, great work everyone! 🙂
I would appreciate reviews from clients that have worked on implementing this.
Contributor
|
LGTM. Amazing addition to Ethereum network feature set. |
Member
|
All, I believe this PR is ready to be merged. I know some clients have already implemented this and I can confirm that at least one client passes all of the FCR tests from the latest version of this PR. If for whatever reason there is an issue, we can always follow up with a fix. Great work everyone! |
This was referenced May 1, 2026
GrapeBaBa
added a commit
to ChainSafe/lodestar-z
that referenced
this pull request
May 1, 2026
Add empty FastConfirmation module skeleton with struct fields, init/deinit, and CONFIRMATION_BYZANTINE_THRESHOLD config constant. Spec helpers and algorithm follow in subsequent commits. Spec: ethereum/consensus-specs#4747 Reference: Lighthouse PR sigp/lighthouse#8951
3 tasks
nflaig
pushed a commit
to ethereum/beacon-APIs
that referenced
this pull request
May 11, 2026
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.
nflaig
pushed a commit
to ChainSafe/lodestar
that referenced
this pull request
Jun 7, 2026
**Motivation** Introduce assumption based fast confirmation rule. **Description** Specs: ethereum/consensus-specs#4747
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
10 participants
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.
Introduction
This PR introduces a modified version of the Fast Confirmation Rule algorithm introduced in #3339.
Modified algorithm starts its confirmed chain from a safe checkpoint and attempts to advance a confirmed block
at the beginning of each slot by finding the most recent confirmed block in the canonical chain. Then the
confirmed_rootis kept in theStoreand is used as the starting point of the algorithm run during the next slot. This iterative approach is one of the main differences comparing to the original version.A new version also have a few modifications improving the algorithm performance, i.e. reducing distance to the most recent confirmed block in e.g. empty slot case.
There is A Short Explainer covering the logic and rationale of the modified version of the algorithm.
Performance
Changeset
Storeis extended with three fields, one of them isconfirmed_rootand the other two are required for the algorithm needs. Alternatively, there can be a separateFCRStoreclass, however, it reduces readability of the spec.get_latest_message_epochis introduced, because Gloas replacesepochwithslot, but the algorithm needs access toLatestMessage.epochon_slot_after_attestations_appliedhandler that basically does two things:get_latest_confirmedfunction and updatesstore.confirmed_rootStoremore convenientget_latest_confirmedfunction which does several underlying callssafeblock is switched fromstore.justified_checkpoint.roottostore.confirmed_rootDependencies
Comparing to the Fork Choice implementation the algorithm has the following dependencies:
Testing
Tests are planned to be a part of a separate PR. The main idea behind tests is to extend the Fork Choice test format with
on_slot_after_attestations_appliedhandler andconfirmed_rootproperty check and defined a separate FCR generator.ToDo
get_weightandget_proposer_score#4746