Add checkpoint root to proposer preferences - #5190
Merged
Merged
Conversation
jtraglia
reviewed
Apr 28, 2026
nflaig
force-pushed
the
proposer-preferences
branch
from
April 28, 2026 21:55
92d5c86 to
10401f5
Compare
nflaig
marked this pull request as ready for review
April 28, 2026 21:58
jtraglia
approved these changes
Apr 28, 2026
jtraglia
left a comment
jtraglia
left a comment
Member
There was a problem hiding this comment.
Looks great. We reviewed this together in person.
nflaig
commented
Apr 29, 2026
| - _[IGNORE]_ The `signed_proposer_preferences` is the first valid message | ||
| received from the validator with index `preferences.validator_index` and the | ||
| given slot `preferences.proposal_slot`. | ||
| `preferences.proposal_slot <= current_slot`. |
Member
Author
There was a problem hiding this comment.
noticed the previous check was correct, opened #5191 to fix this
jtraglia
pushed a commit
that referenced
this pull request
Apr 29, 2026
We wanna check if `proposal_slot` is greater than the `current_slot`, ie. not in the past, in #5190 this check was mistakenly inverted.
4 tasks
nflaig
added a commit
to ChainSafe/lodestar
that referenced
this pull request
Apr 30, 2026
pull Bot
pushed a commit
to Hawthorne001/prysm
that referenced
this pull request
May 13, 2026
**What type of PR is this?**
Bug fix
**What does this PR do? Why is it needed?**
The proposer preference cache was keyed by slot only
(`map[Slot]ProposerPreference`) with first-write-wins semantics. During
a reorg that changes the proposer shuffling (different RANDAO at epoch
boundary), a new proposer's preferences for the same slot would be
rejected because the slot already had an entry. This caused:
- Gossip dedup blocking the new proposer's preferences
- Bid validation using the wrong validator's fee recipient and gas limit
- Payload attributes using the wrong fee recipient
Makes the proposer preferences cache reorg-safe by re-keying from `slot`
to `(slot, validatorIndex)`. After a reorg that changes the proposer
shuffling, the correct proposer's preferences are resolved dynamically
from the head state's proposer lookahead.
## Reproducing reorg testing with Kurtosis
To validate this change under real reorgs, add a temporary broadcast
delay flag that is NOT part of this PR. Apply the following patch
locally, build new images, and run with the kurtosis config below.
### 1. Patch `config/features/flags.go`
Add a flag variable before `DisableDutiesV2`:
```go
reorgTestBroadcastDelay = &cli.DurationFlag{
Name: "reorg-test-broadcast-delay",
Usage: "(Testing): Delays P2P block broadcast by this duration while processing the block locally first.",
}
```
Add `reorgTestBroadcastDelay,` to the `BeaconChainFlags` slice.
### 2. Patch `config/features/config.go`
Add a field to the `Flags` struct:
```go
ReorgTestBroadcastDelay time.Duration
```
Add to `ConfigureBeaconChain()` before `Init(cfg)`:
```go
if ctx.IsSet(reorgTestBroadcastDelay.Name) {
cfg.ReorgTestBroadcastDelay = ctx.Duration(reorgTestBroadcastDelay.Name)
}
```
### 3. Patch `beacon-chain/rpc/prysm/v1alpha1/validator/proposer.go`
Add `"github.com/OffchainLabs/prysm/v7/config/features"` to imports.
Replace `broadcastReceiveBlock` with:
```go
func (vs *Server) broadcastReceiveBlock(ctx context.Context, wg *sync.WaitGroup, block interfaces.SignedBeaconBlock, root [fieldparams.RootLength]byte) error {
delay := features.Get().ReorgTestBroadcastDelay
if delay > 0 {
// Receive locally first, then delay broadcast — creates a divergent fork.
vs.BlockNotifier.BlockFeed().Send(&feed.Event{
Type: blockfeed.ReceivedBlock,
Data: &blockfeed.ReceivedBlockData{SignedBlock: block},
})
if err := vs.BlockReceiver.ReceiveBlock(ctx, block, root, nil); err != nil {
return errors.Wrap(err, "receive block")
}
time.Sleep(delay)
if err := vs.broadcastBlock(ctx, wg, block, root); err != nil {
return errors.Wrap(err, "broadcast block")
}
return nil
}
if err := vs.broadcastBlock(ctx, wg, block, root); err != nil {
return errors.Wrap(err, "broadcast block")
}
vs.BlockNotifier.BlockFeed().Send(&feed.Event{
Type: blockfeed.ReceivedBlock,
Data: &blockfeed.ReceivedBlockData{SignedBlock: block},
})
if err := vs.BlockReceiver.ReceiveBlock(ctx, block, root, nil); err != nil {
return errors.Wrap(err, "receive block")
}
return nil
}
```
### 4. Kurtosis config (`gloas-config-4node-reorg.yml`)
```yaml
participants:
el:
el_type: geth
el_image: ethpandaops/geth:glamsterdam-devnet-0
cl:
cl_type: prysm
cl_image: gcr.io/offchainlabs/prysm/beacon-chain:latest
vc_image: gcr.io/offchainlabs/prysm/validator:latest
supernode: true
count: 2
vc_extra_params:
- "--verbosity=debug"
- el_type: geth
el_image: ethpandaops/geth:epbs-devnet-0
cl_type: prysm
cl_image: gcr.io/offchainlabs/prysm/beacon-chain:latest
vc_image: gcr.io/offchainlabs/prysm/validator:latest
supernode: true
count: 2
cl_extra_params:
- "--reorg-test-broadcast-delay=5s"
vc_extra_params:
- "--verbosity=debug"
network_params:
fulu_fork_epoch: 0
gloas_fork_epoch: 2
seconds_per_slot: 4
genesis_delay: 40
additional_services:
- dora
global_log_level: debug
dora_params:
image: ethpandaops/dora:gloas-support
```
### 5. Run and monitor
```bash
kurtosis run --enclave gloas-reorg github.com/ethpandaops/ethereum-package \
--args-file gloas-config-4node-reorg.yml
# Check for reorgs (delayed nodes experience them)
kurtosis service logs gloas-reorg cl-3-prysm-geth --all 2>&1 | grep "Chain reorg occurred"
# Check proposer preferences are flowing
kurtosis service logs gloas-reorg cl-1-prysm-geth --all 2>&1 | grep "Processed signed proposer"
# Key log: cache accepted a different validator's preference for a slot that already had one.
# This is the reorg-safety signal — proves the (slot, validatorIndex) keying works.
kurtosis service logs gloas-reorg cl-3-prysm-geth --all 2>&1 | grep "possible reorg"
```
With 4-second slots and a 5-second delay, the delayed nodes' blocks
arrive after the next slot begins, reliably triggering reorgs (depth
2-3).
### Logs to look for
| Log message | Source | Meaning |
|---|---|---|
| `Chain reorg occurred` | `blockchain` | A reorg happened on this node
|
| `New proposer preference for slot that already has a different
validator (possible reorg)` | `cache` | The cache accepted a second
validator's preference for the same slot — proves the reorg-safe keying
works |
| `Processed signed proposer preferences` | `rpc/validator` | VC
submitted preferences via RPC (shows broadcast/duplicate/total counts) |
**Which issues(s) does this PR fix?**
Fixes #OffchainLabs#16616
related specs
ethereum/consensus-specs#5196
ethereum/consensus-specs#5190
ethereum/consensus-specs#5191
**Other notes for review**
**Acknowledgements**
- [x] I have read
[CONTRIBUTING.md](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md).
- [x] I have included a uniquely named [changelog fragment
file](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md#maintaining-changelogmd).
- [x] I have added a description with sufficient context for reviewers
to understand this PR.
- [x] I have tested that my changes work as expected and I added a
testing plan to the PR description (if applicable).
---------
Co-authored-by: terence <terence@prysmaticlabs.com>
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
2 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.
Adds
checkpoint_roottoProposerPreferencesto be able to identify the proposer's branch, allowing preferences to be broadcast and validated even when receivers and proposers see different heads.