Optimisations relating to get_expected_withdrawals (#9314)

Tweaking/optimising `get_expected_withdrawals` on the pre-Gloas path, after the removal of some optimisations in:

- https://github.com/sigp/lighthouse/pull/9102


  - Remove `prepare_beacon_proposer` calls from `register_validator`. These calls were: heavily duplicated, happening _too early_ (at the start of the slot before the block arrived), expensive on epoch boundaries (forcing an early epoch transition), _and_ unnecessary. They are completely safe to remove because the scheduled proposer preparation routine exists.
- Instrument `get_expected_withdrawals`/`prepare_beacon_proposer` to find more unexpected callers.


Co-Authored-By: Michael Sproul <michael@sigmaprime.io>

Co-Authored-By: Tan Chee Keong <tanck@sigmaprime.io>

Co-Authored-By: Michael Sproul <michaelsproul@users.noreply.github.com>
This commit is contained in:
Michael Sproul
2026-07-02 17:10:40 +10:00
committed by GitHub
parent 369decc1df
commit 1587f1e1d2
2 changed files with 6 additions and 13 deletions

View File

@@ -406,6 +406,10 @@ impl ProposerPreparationDataEntry {
}
}
// NOTE: This key should arguably include the `suggested_fee_recipient`, as it is part of the
// `Proposer::payload_attributes` value that is cached based on it. However, in some cases where
// this key is constructed the fee recipient is not straight-forward to determine. Therefore we
// accept the risk of loading a stale fee recipient within the timespan of a single slot.
#[derive(Hash, PartialEq, Eq)]
pub struct ProposerKey {
slot: Slot,

View File

@@ -664,6 +664,8 @@ pub fn post_validator_register_validator<T: BeaconChainTypes>(
.unzip();
// Update the prepare beacon proposer cache based on this request.
// This data will get picked up by the next scheduled run of
// `prepare_beacon_proposer`.
execution_layer
.update_proposer_preparation(
current_epoch,
@@ -671,19 +673,6 @@ pub fn post_validator_register_validator<T: BeaconChainTypes>(
)
.await;
// Call prepare beacon proposer blocking with the latest update in order to make
// sure we have a local payload to fall back to in the event of the blinded block
// flow failing.
chain
.prepare_beacon_proposer(current_slot)
.await
.map_err(|e| {
warp_utils::reject::custom_bad_request(format!(
"error updating proposer preparations: {:?}",
e
))
})?;
info!(
count = filtered_registration_data.len(),
"Forwarding register validator request to connected builder"