perf(beacon): fuse electra epoch steps 2-9 into one registry pass

[MegaRedHand]

One of three alternative implementations of the same follow-up to lambdaclass/ethlambda_private#37 (epoch participation without per-index registry reads): (a) #630, (b) #632, (c) this PR. Stacked on (b): this PR's diff is the fusion only, and it targets (b)'s branch.

Motivation

After (b), electra and fulu still walk the tree-backed registry once per remaining epoch step: registry updates, slashings, pending deposits and effective-balance updates. Several of those steps also recompute get_total_active_balance, which descends once per active validator. This is option (c) of the plan, the Lighthouse-style single pass (process_epoch_single_pass).

Change: fuse electra/fulu epoch steps 2-9 into one loop

stf::epoch::single_pass visits each validator once, in index order, working on a local copy of the validator and its balance. Per validator, in spec order:

1. inactivity score;
2. rewards and penalties;
3. registry action (queue, eject or activate);
4. slashing penalty;
5. planned deposit top-up;
6. effective-balance update.

Changes are written back after the loop. What depends on more than one validator stays outside it, as in Lighthouse:

• Exit churn: the cursor is advanced locally in index order and written back once.
• Pending deposits: the queue is planned before the loop. A deposit counts as "exited" if the validator already has an exit or this epoch's registry update will eject it. Top-ups of existing validators apply inside the loop; deposits that create validators apply after it, and one registry walk serves all pubkey lookups.
• Consolidations: pending consolidations run after the loop. The effective-balance update of every validator they name, and of every validator created by deposits, waits until then.
• Total active balance: taken from the summary and reused for slashings and every churn limit. It equals get_total_active_balance through step 8.

The hysteresis test both effective-balance updates use is now one checked leaves_hysteresis_band: a balance near u64::MAX is an ArithmeticOverflow, as in the spec and Lighthouse's safe_add, rather than a debug panic or a release wrap that moves the effective balance. It keeps the spec's short-circuit or.

The genesis epoch, and states whose registry-sized lists differ in length, fall back to the step-by-step path. The step functions stay public and callable in isolation for the fixtures. The per-step rules both paths share were factored out so both run the same code: registry action, slashing penalty, effective-balance hysteresis, inactivity score and the exit-cursor advance.

Testing

• In debug builds, a registry of up to 4096 validators also runs through the specification-shaped steps 1-9 on a clone, and the two full post-states must have equal hash_tree_root. A mismatch names the differing fields.
• A randomized fused-vs-unfused test runs 800 electra and fulu cases. They cover ejections that move the churn cursor, activations and the activation queue, slashings, every pending-deposit branch (including new pubkeys with valid and invalid signatures), and processed, slashed and not-yet-withdrawable consolidations. Two deliberately injected bugs were caught within a few seeds. About one state in ten carries a near-u64::MAX balance, since one now fails the whole epoch; those cases check that both paths fail together. As in (b), the finalized epoch stays at or behind the previous epoch.
• Clippy -D warnings and the ethlambda-state-transition lib tests pass, including the dev-profile Test minimal preset run, where overflow checks are on.
• Beacon spec filters epoch_processing, rewards, sanity, finality, random, fork_choice and transition pass on both presets. That run predates the rebase onto (b)'s finality-delay fix and the checked hysteresis; CI's beacon spec jobs cover both.

Over (b), this saves about 200 ms per epoch-start block and nothing on other blocks. That is more than the plan estimated, probably because the fusion also removes the repeated total-active-balance calls and the per-deposit pubkey scans (not profiled). A per-epoch total cache (follow-up 01) and a pubkey-to-index map would recover part of that gain more simply.

Benchmark (all three options)

ethlambda benchmark import replay on ethlambda-5: cargo build --release, mainnet corpus of 128 blocks (slots 15279073..=15279200, 4 epoch-start blocks), legs interleaved base a b c for two rounds. Base against base: 0.996. Every leg imported all 128 blocks.

	base (c913728)	(a) iterator passes	(b) summary pass	(c) single pass
process wall	104.0 s	96.1 s	92.0 s	91.0 s
user CPU	215.1 s	208.4 s	205.1 s	203.8 s
stf, epoch-start block (mean of 4)	1503 ms	1126 ms	912 ms	709 ms
stf p50, other blocks	577 ms	517 ms	478 ms	479 ms
paired stf vs base (ratio of totals)	1	0.869	0.797	0.785
get_head p50	201 ms	214 ms	226 ms	225 ms
peak RSS	3.88 GiB	3.93 GiB	4.04 GiB	4.04 GiB

• The per-block saving comes from the pulled-up tip, which reruns justification on every imported block.
• (c) gains nothing over (b) on ordinary blocks, since their per-block path is the same.
• get_head rises as stf falls, although no option touches the head computation. This is probably contention with the background state writer, as seen in earlier import benchmarks; it is not verified. Block wall time still falls.

Moved

• Moved from lambdaclass/ethlambda_private#62, now that beacon-chain-integration lives on this repo.
• Stacked on perf(beacon): run epoch steps 1-3 over one registry scan #632 (was lambdaclass/ethlambda_private#61); its head, which carries beacon-chain-integration @ c79fabd5, is merged into the branch.

[MegaRedHand]

Import-replay benchmark (re-measured on the current base)

Method. ethlambda benchmark import replay, release build, 128 consecutive mainnet blocks (slots 15279073..=15279200, 4 of them epoch-start blocks) on a 16-core host. This PR's leg and a base leg (beacon-chain-integration) were interleaved, 2 rounds each; the table shows the mean of the two. Both legs carry #651, so stf excludes the state-writer hand-off wait. Block roots were identical to the base in every leg. Base vs base noise floor: 1.004.

	base	this PR (includes #632)	change
stf epoch-start block (mean of 4)	1505 ms	713 ms	−53%
stf ordinary block p50	577 ms	476 ms	−18%
get_head p50	200 ms	223 ms	+11%
block wall p50	777 ms	696 ms	−10%
user CPU (whole run)	214.7 s	203.8 s	−5%
peak RSS	3.90 GiB	4.33 GiB	+0.43
paired stf, ratio of totals (round 1 / round 2)		0.789 / 0.776

Per epoch-start block (stf ms):

slot	base	this PR
15279104	1607	835
15279136	1521	727
15279168	1486	683
15279200	1405	609

This reproduces the earlier measurement on the older base (epoch-start 1503 → 709 ms, ordinary 577 → 479 ms), including the small get_head rise. That rise is probably contention with the background state writer's encode, which now overlaps get_head more; not verified.

All five performance PRs together (#647, #648, #649, #650, this one), measured with a 1 s delay between blocks so the state writer drains (--block-delay, #651):

• ordinary stf 527 → 163 ms; epoch-start 1440 → 420 ms;
• block wall p50 729 → 185 ms (3.9x); user CPU −30%.

In that build, the fused pass's inactivity-score, balance and validator writes go through #647's in-order write cursor, and the scores are #650's tree list.