[KaloyanTanev]

Fix the first gloas epoch's proposer preferences being rejected with InvalidDependentRoot. VCs prefetching the epoch before the fork get its v1 proposer duties cached with a provisional dependent_root, the head root at fetch time, which Prysm signs into the next epoch's preferences.

The duties cache no longer caches v1 proposer duties from the epoch before the gloas fork onwards, from which VCs resolve their duties via v2. The scheduler resolves proposer duties via v2 from the gloas fork only, since older beacon nodes do not serve it, and the synthetic proposer wrapper passes v2 metadata through. Mock VCs only submit preferences from gloas.

category: bug
ticket: #4324

[codecov]

Codecov Report

❌ Patch coverage is 70.37037% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.61%. Comparing base (957f2dd) to head (903e8ee).

Files with missing lines	Patch %	Lines
app/eth2wrap/synthproposer.go	71.42%	4 Missing ⚠️
app/vmock.go	0.00%	2 Missing ⚠️
app/app.go	0.00%	1 Missing ⚠️
core/scheduler/scheduler.go	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4794      +/-   ##
==========================================
+ Coverage   67.59%   67.61%   +0.01%     
==========================================
  Files         254      254              
  Lines       33589    33610      +21     
==========================================
+ Hits        22705    22724      +19     
- Misses      10883    10885       +2     
  Partials        1        1              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
10.4% Duplication on New Code

See analysis details on SonarQube Cloud

[OisinKyne]

Two questions before merging:

1. The scheduler now requires /eth/v2/validator/duties/proposer on every fork, mainnet included.
   • go-eth2-client's ProposerDutiesV2 has no fallback to v1. If any supported beacon node lacks the v2 endpoint, the scheduler can't resolve proposer duties, and every proposal is missed silently.
   • The minimum beacon node version check still allows Lighthouse v8.0.0, and I don't know which versions added v2 proposer duties.
   • Either fall back to v1 on 404/405, or use v2 only once gloas is active (or one epoch before). That's cheap, and safer for a release that also goes to mainnet.
2. The VC can race the invalidation. It happens in the slot subscriber at the first slot of G-1. A VC that refreshes its duties at that same slot can be served the stale cached entry before charon drops it. Has this been checked against Prysm's refresh timing, or seen working on a devnet fork?
   • A more general option: never keep v1 duties cached for an epoch whose dependent-root slot hadn't passed when they were fetched. That would also stop this from coming back at the next fork.