perf(epoch): replace AutoHashMap with array lookup in reward/penalty caches by lodekeeper-z · Pull Request #286 · ChainSafe/lodestar-z

lodekeeper-z · 2026-03-27T07:12:29Z

Summary

Replace heap-allocated AutoHashMap keyed by effective_balance_increment with stack-allocated fixed-size arrays in three epoch processing functions:

getRewardsAndPenaltiesAltair
getAttestationDeltas
processSlashings

Motivation

effective_balance_increment is bounded: max 32 pre-Electra, max 2048 post-Electra. The existing AutoHashMap performs unnecessary heap allocation and hashing in the hot per-validator loops during epoch transitions (~1.1M validators on mainnet).

A fixed-size [max_increment]?T array provides:

O(1) lookup (direct indexing vs hash probe)
Zero allocation (stack-allocated, no heap pressure)
Better cache locality (contiguous memory)

Changes

Replace std.AutoHashMap with [max_increment]?RewardPenaltyItem / [max_increment]?u64 arrays
Remove now-unused allocator parameters from getRewardsAndPenaltiesAltair, getAttestationDeltas, processSlashings, and getRewardsAndPenalties
Update all call sites

Testing

All test:state_transition tests pass.

Refs: #243

🤖 Generated with AI assistance

…caches Replace heap-allocated AutoHashMap keyed by effective_balance_increment with stack-allocated fixed-size arrays in three epoch processing functions: - getRewardsAndPenaltiesAltair - getAttestationDeltas - processSlashings effective_balance_increment is bounded (max 32 pre-Electra, max 2048 post-Electra), so a fixed array provides O(1) lookup with zero allocation overhead. This eliminates hashing and heap allocation in the hot per-validator loops during epoch transitions. Also removes now-unused allocator parameters from these functions, simplifying call signatures. Refs: ChainSafe#243 🤖 Generated with AI assistance

gemini-code-assist · 2026-03-27T07:12:37Z

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request optimizes the performance of epoch processing by replacing dynamic hash map lookups with direct array indexing. By leveraging the bounded nature of effective balance increments, the changes reduce memory pressure and improve cache locality in hot validator loops, resulting in more efficient state transitions.

Highlights

Performance Optimization: Replaced heap-allocated std.AutoHashMap with stack-allocated fixed-size arrays in critical epoch processing functions to eliminate unnecessary allocations and hashing overhead.
API Cleanup: Removed redundant allocator parameters from getRewardsAndPenaltiesAltair, getAttestationDeltas, processSlashings, and getRewardsAndPenalties as they are no longer needed for cache management.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request optimizes epoch state transitions by replacing dynamic std.AutoHashMap caches with fixed-size arrays in getAttestationDeltas, getRewardsAndPenaltiesAltair, and processSlashings. These changes eliminate the need for an Allocator in several functions, reducing overhead from hashing and memory allocation in performance-critical validator loops. The cache sizes are determined at compile-time based on the Electra preset. I have no feedback to provide as the changes align with the performance goals of the repository.

processSlashings signature changed in this PR to remove the allocator parameter (no longer needed after switching from AutoHashMap to array lookup). Update the two call sites in bench/state_transition/process_epoch.zig. 🤖 Generated with AI assistance

…enalties signatures processSlashings no longer takes an allocator param. getRewardsAndPenalties no longer takes an allocator param. 🤖 Generated with AI assistance

twoeths · 2026-03-30T08:04:41Z

+    // effectiveBalance is a multiple of EFFECTIVE_BALANCE_INCREMENT and bounded by max effective balance,
+    // so effective_balance_increment has a small range (0..max_increment). Use a fixed array for O(1) lookup
+    // instead of a HashMap — avoids allocation and hashing overhead in the hot validator loop.
+    const max_increment = comptime preset.MAX_EFFECTIVE_BALANCE_ELECTRA / preset.EFFECTIVE_BALANCE_INCREMENT + 1;


getAttestationDeltas() is supposed for phase0 so need to use MAX_EFFECTIVE_BALANCE instead

also would be great to add a comment for this function stating phase0

Fixed in 8f728c3. Changed to use MAX_EFFECTIVE_BALANCE (32 increments) since this function is phase0-only. Added comment noting it's phase0.

twoeths · 2026-03-30T08:06:14Z

+    // so effective_balance_increment has a small range (0..max_increment). Use a fixed array for O(1) lookup
+    // instead of a HashMap — avoids allocation and hashing overhead in the hot validator loop.
+    const max_increment = comptime preset.MAX_EFFECTIVE_BALANCE_ELECTRA / EFFECTIVE_BALANCE_INCREMENT + 1;
+    var reward_penalty_item_cache: [max_increment]?RewardPenaltyItem = .{null} ** max_increment;


for pre-electra, use MAX_EFFECTIVE_BALANCE to save memory

Fixed in 8f728c3. Now uses comptime fork selection: MAX_EFFECTIVE_BALANCE (33 slots) for pre-Electra forks, MAX_EFFECTIVE_BALANCE_ELECTRA (2049 slots) for Electra+. Same for processSlashings.

twoeths · 2026-03-30T08:12:19Z

@@ -74,7 +73,7 @@ pub fn getRewardsAndPenaltiesAltair(

        const effective_balance_increment = effective_balance_increments[i];


it's a little bit unsafe because effective_balance_increment is modeled as u16 pub const EffectiveBalanceIncrements = std.ArrayList(u16);
maybe switch it to u11 to match 2048 as in electra?

Valid concern. The u16 type allows values up to 65535 but the array is at most 2049. With the fork-aware sizing now in place, the arrays are even smaller (33 for phase0/pre-Electra).

Changing EffectiveBalanceIncrements from ArrayList(u16) to a narrower type (u12 would cover 0..2048) is a broader change touching epoch_cache, epoch_transition_cache, and all consumers. Worth doing as a separate PR — want me to open one?

go for it @lodekeeper-z

- getAttestationDeltas (phase0 only): use MAX_EFFECTIVE_BALANCE (32 increments) - getRewardsAndPenaltiesAltair: use comptime fork to select max (32 pre-Electra, 2048 post) - processSlashings: same fork-aware sizing Addresses review feedback from twoeths on PR ChainSafe#286. 🤖 Generated with AI assistance

twoeths

looks good to me

lodekeeper-z requested a review from a team as a code owner March 27, 2026 07:12

gemini-code-assist Bot reviewed Mar 27, 2026

View reviewed changes

lodekeeper-z added 2 commits March 27, 2026 07:32

fix: update spec test runners for new processSlashings/getRewardsAndP…

d7525b6

…enalties signatures processSlashings no longer takes an allocator param. getRewardsAndPenalties no longer takes an allocator param. 🤖 Generated with AI assistance

GrapeBaBa previously approved these changes Mar 28, 2026

View reviewed changes

twoeths reviewed Mar 30, 2026

View reviewed changes

lodekeeper-z dismissed GrapeBaBa’s stale review via 8f728c3 March 30, 2026 09:46

twoeths approved these changes Mar 31, 2026

View reviewed changes

GrapeBaBa approved these changes Apr 1, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

perf(epoch): replace AutoHashMap with array lookup in reward/penalty caches#286

perf(epoch): replace AutoHashMap with array lookup in reward/penalty caches#286
lodekeeper-z wants to merge 4 commits intoChainSafe:mainfrom
lodekeeper-z:perf/array-lookup-epoch-cache

lodekeeper-z commented Mar 27, 2026

Uh oh!

gemini-code-assist Bot commented Mar 27, 2026

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

twoeths Mar 30, 2026

Uh oh!

lodekeeper-z Mar 30, 2026

Uh oh!

lodekeeper-z Mar 30, 2026

Uh oh!

twoeths Mar 30, 2026

Uh oh!

lodekeeper-z Mar 30, 2026

Uh oh!

twoeths Mar 30, 2026

Uh oh!

lodekeeper-z Mar 30, 2026

Uh oh!

twoeths Mar 30, 2026

Uh oh!

twoeths left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -74,7 +73,7 @@ pub fn getRewardsAndPenaltiesAltair(

		const effective_balance_increment = effective_balance_increments[i];

Conversation

lodekeeper-z commented Mar 27, 2026

Summary

Motivation

Changes

Testing

Uh oh!

gemini-code-assist Bot commented Mar 27, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

twoeths left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants