Skip to content

SIMD-0496: Integer Inflation Rewards#496

Open
ksn6 wants to merge 3 commits intosolana-foundation:mainfrom
ksn6:0496-integer-inflation-rewards
Open

SIMD-0496: Integer Inflation Rewards#496
ksn6 wants to merge 3 commits intosolana-foundation:mainfrom
ksn6:0496-integer-inflation-rewards

Conversation

@ksn6
Copy link
Copy Markdown
Contributor

@ksn6 ksn6 commented Mar 18, 2026

Overview

Specifies the replacement of f64 arithmetic in the inflation reward pipeline with fixed-point u128 integer math, gated behind a feature flag.

Implementation: anza-xyz/agave#10335

Motivation

IEEE-754 floating-point is non-deterministic across CPU architectures. The current inflation reward calculation uses f64 throughout, which is a latent consensus-splitting bug as the validator fleet diversifies. This SIMD specifies exact integer arithmetic that all implementations must replicate bit-for-bit.

@simd-bot
Copy link
Copy Markdown

simd-bot bot commented Mar 18, 2026

Hello ksn6! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here.

This PR requires the following approvals before it can be merged:

Once all requirements are met, you can merge this PR by commenting /merge.

Copy link
Copy Markdown
Contributor

@AshwinSekar AshwinSekar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

concept ACK, gave a C- math student review, we should get a big brain to review as well.

type: Core
status: Idea
created: 2026-03-18
feature: (to be assigned upon acceptance)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might as well generate the feature key now and paste the pubkey here


For mainnet's `Inflation::default()`:

| Field | f64 | Scaled u128 |
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not getting these values when I run f64_to_scaled on my dev box. This is what I get:

0.08   | 92233720368547760
0.015  | 17293822569102704
0.85   | 979983278915819904
0.05   | 57646075230342352


#### `fixed_ln`: natural log via `atanh` series

For `x` in `[S/2, S]` (i.e. real values in [0.5, 1.0]):
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit : Inflation::new_fixed and Inflation::new_pico use taper = 1.0 so we should define fixed_ln(0) as well

remainder = year_nanos % NANOS_PER_YEAR

int_part = fixed_pow(decay_base_scaled, full_years)
frac_part = fixed_exp(remainder * fixed_ln(decay_base_scaled) / NANOS_PER_YEAR)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm assuming decay_base_scaled = (1 - taper)^year?
It would be good to define all these variables in terms of the 4 initially provided, lil confusing as is

### Validator and foundation rates

```text
foundation_share = total * foundation_scaled / S (if year_nanos < foundation_term_nanos)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: here too would be good to explicitly define foundation_term_nanos in terms of Inflation.foundation_term w/ rounding rule

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants