From 1587f1e1d2da8050e590973cb4fb9b02f37d9552 Mon Sep 17 00:00:00 2001 From: Michael Sproul Date: Thu, 2 Jul 2026 17:10:40 +1000 Subject: [PATCH] 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 Co-Authored-By: Tan Chee Keong Co-Authored-By: Michael Sproul --- beacon_node/execution_layer/src/lib.rs | 4 ++++ beacon_node/http_api/src/validator/mod.rs | 15 ++------------- 2 files changed, 6 insertions(+), 13 deletions(-) diff --git a/beacon_node/execution_layer/src/lib.rs b/beacon_node/execution_layer/src/lib.rs index b255e1b75d..523f06b7ff 100644 --- a/beacon_node/execution_layer/src/lib.rs +++ b/beacon_node/execution_layer/src/lib.rs @@ -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, diff --git a/beacon_node/http_api/src/validator/mod.rs b/beacon_node/http_api/src/validator/mod.rs index 1488f13898..b37bd7d37d 100644 --- a/beacon_node/http_api/src/validator/mod.rs +++ b/beacon_node/http_api/src/validator/mod.rs @@ -664,6 +664,8 @@ pub fn post_validator_register_validator( .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( ) .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"