Integer overflow in attestation reward calculations for large validator balances

[dbxe]

Describe the bug

The attestation reward calculations in AttestationsDelta overflow when validators have large effective balances.

Expected Behaviour

Attestation reward calculations should handle large validator effective balances without integer overflow, producing mathematically correct results.

Current Behaviour

The multiplication exceeds uint64 limits before division occurs.

Has this worked before in a previous version?

As far as I know, it has not.

🔬 Minimal Reproduction

As an example, the overflow can be reproduced by running a network with 1024 validators each with an effective balance of 10M eth (10000000000000000 gwei), with the other consensus configuration parameters set to the mainnet default.

These conditions result in the following calculation for attDelta.HeadReward.

(200000000 * 14 * (10240000000000000000 / 1000000000)) / (10240000000 * 64)

The numerator silently overflows as it exceeds the uint64 max value, and returns a mathematically incorrect head reward.

overflow_reproduction.txt

Error

Platform(s)

Mac (Apple Silicon)

What version of Prysm are you running? (Which release)

v6.0.4

Anything else relevant (validator index / public key)?

No response

[dbxe]

@potuz

Thanks for your earlier feedback. After reviewing the consensus-layer spec, we reached the same conclusion: with today’s mainnet parameters there’s no realistic overflow risk, and even at the validator registry limit we’re still several orders of magnitude from uint64 overflow.

That said, because BASE_REWARD_FACTOR and MAX_EFFECTIVE_BALANCE are both configuration parameters with no formal upper bounds in the spec, a spec-compatible network could choose values that would cause the current baseReward * weight * attested_increments multiplication to overflow, even if the final quotient would fit in a uint64.

Even if mainnet itself never changes these values, preventing potential overflow and future-proofing the code can be a worthwhile improvement, especially if it can be done without performance regressions or altering current behaviour.

If we were to open a PR that preserves the exact arithmetic result (no rounding or calculation discrepancies) and avoids big.Int allocations and associated performance costs, would the maintainers be open to considering that change? Our thinking is a small, provably-equivalent helper (e.g. GCD-based mul3div2 refactor) could widen the safe parameter envelope without affecting current Ethereum behaviour.

Thank you for your consideration.