fix: emit payload_attributes for local proposals by default

[eth2353]

Motivation

I was looking at the payload_attributes SSE event and noticed Lodestar behaves slightly differently from other clients. Lodestar emits the event for every slot when the --emitPayloadAttributes flag is provided, and doesn't emit it under any other condition.

Whereas other clients (Teku, Prysm, Lighthouse, Grandine) emit the event if a local proposal is expected in the next slot, and have a CLI flag that allows them to emit the event for every slot.

Description

This PR aligns Lodestar's default behavior with other clients. It adds default payload_attributes SSE emission for local block proposals, while preserving the existing --emitPayloadAttributes flag as an override to emit the event for every slot.

The emitted event now uses the proposal’s actual fee recipient and the prepared parent root.

AI Assistance Disclosure

• External Contributors: I have read the contributor guidelines and disclosed my usage of AI below.

I consulted Codex (GPT-5.4) to help draft the implementation.

[gemini-code-assist]

Code Review

This pull request updates the PrepareNextSlotScheduler to improve the emission of payloadAttributes SSE events. The logic now triggers an event if the node is the next proposer or if the emitPayloadAttributes flag is set. Additionally, it ensures the parentBlockRoot uses the updatedHeadRoot and corrects the feeRecipient default to a 20-byte zero address. I have no feedback to provide as the review comments were explanatory in nature.

[nflaig]

should align that with other clients, I am curious what you are using it for @eth2353

[nflaig]

we just discussed this here #9209, it's definitely correct to emit updatedHeadRoot if we are the proposer in case of a proposer boost reorg, but would like to get +1 from @twoeths

[twoeths]

looks right to me too

• if we're the next proposal, updatedHeadRoot is the one we'll go with
• if not, updatedHeadRoot is same to headRoot

[nflaig]

lgtm, leaving up for @twoeths for final approval/merge

[eth2353]

I am curious what you are using it for @eth2353

I'm playing around with the idea of Vero talking to relays directly, like Vouch does. For that I needed an EL parent_hash and this SSE topic seemed like the best place to get it (without the overhead of fetching full blocks).

The --emitPayloadAttributes CLI flag works fine but other clients' behavior is different (and more intuitive imo).

[nflaig]

@eth2353 I think I broke your PR 😓

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.52%. Comparing base (07875b3) to head (334df3d).
⚠️ Report is 1 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #9258      +/-   ##
============================================
- Coverage     52.53%   52.52%   -0.01%     
============================================
  Files           848      848              
  Lines         61309    61304       -5     
  Branches       4510     4510              
============================================
- Hits          32206    32201       -5     
  Misses        29038    29038              
  Partials         65       65              

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.