Remove Inactive Stakes from Rewards

Summary

The partitioned epoch rewards process currently requires all stake accounts, including inactive stakes, to be considered when computing the lattice hash and rewards partition count. But inactive stakes do not contribute to stake weight or rewards, so they shouldn't be required.

This proposal changes the rewards process to only include activating, active, and deactivating stake accounts.

Motivation

The Solana runtime currently includes inactive stake accounts during partitioned epoch reward calculations, which are useless, but consensus critical.

Their inclusion during the rewards period can impact:

1. The number of partitions
2. The lattice hash

As a result, all validator implementations must also include inactive stakes, which is a maintenance burden and potential footgun.

New Terminology

Not new, but "inactive stake" means "a stake with no effective or activating stake".

As a reminder, a deactivating stake has effective stake.

Detailed Design

During epoch rollover from an epoch E to E + 1, all stakes that were inactive in E must not be included in the partitioned epoch rewards phases: calculation and distribution.

Specifically, during epoch rollover, inactive stakes must be excluded from the set of all potential reward-receiving stakes.

During account updates, if a stake account is inactive in both the current and previous epochs, it must be removed from consideration for a validator's stake weight.

As a reminder, during the calculation and distribution phases of partitioned epoch rewards, stake state changes are not allowed through transactions.

This table summarizes the cases and actions to take.

Edge Cases

This case is covered in the design, but it is useful to explain. Stakes going from non-zero effective stake to inactive at the start of epoch E + 1 must be included in the reward set.

During partitioned epoch reward payout, the newly-inactive stake must receive its rewards.

Validator Components Affected

Which validator components are affected by this change?

Alternatives Considered

None.

Impact

Validator development will be simpler since developers no longer need to consider inactive stakes in partitioned epoch rewards.

Security Considerations

None.

Conformance

We will provide a ledger with active, inactive and deactivating stakes at epoch E, covering all cases in the table under "Detailed Design".