From eb5acdb7ddd3856ef2dd00163b448ea0d0463861 Mon Sep 17 00:00:00 2001 From: Etan Kissling Date: Wed, 20 Mar 2024 16:41:56 +0100 Subject: [PATCH] make sure `clearanceState` builds on top of `headState` in chain stall (#6108) The `clearanceState` points to the latest resolved block, regardless of whether that block is canonical according to fork choice. If chain is stalled and we want to prepare for resuming validator duties, we need a recent state according to fork choice to avoid lag spikes and missing slot timings. --- beacon_chain/consensus_object_pools/block_clearance.nim | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/beacon_chain/consensus_object_pools/block_clearance.nim b/beacon_chain/consensus_object_pools/block_clearance.nim index cf2a3dc38..8ca0d6e3d 100644 --- a/beacon_chain/consensus_object_pools/block_clearance.nim +++ b/beacon_chain/consensus_object_pools/block_clearance.nim @@ -143,6 +143,12 @@ proc advanceClearanceState*( # epoch transition ahead of time. # Notably, we use the clearance state here because that's where the block will # first be seen - later, this state will be copied to the head state! + + if chainIsDegraded and dag.clearanceState.latest_block_id != dag.head.bid: + # The last block that was resolved may not be canonical. + # If that's the case, we first have to copy `headState` to `clearanceState` + assign(dag.clearanceState, dag.headState) + let advanced = withState(dag.clearanceState): forkyState.data.slot > forkyState.data.latest_block_header.slot if not advanced or chainIsDegraded: