Version 1.14 introduces a few changes to the native stake program. These changes improve the performance of the network when doing various stake related activities such as delegating stake, and paying out rewards. The changes in 1.14 set the groundwork for more changes slated for future releases, one of these such changes being SIMD-15, “Partitioned Epoch Rewards Distribution."
Vote: Minimum Stake Delegation
One of the stake program changes in v1.14 enables an on-chain vote to take place that, if approved by the validators, will increase the minimum required stake delegation to 1 SOL. Existing stakes below the minimum will be grandfathered in, but will be allowed to deactivate or merge with another stake that results in a stake whose delegation is above the minimum. Once the software release goes live, validators will be provided with a chance to vote on the enablement of this feature through the Feature Proposal Program. The vote window will last 2 weeks. When the vote starts, the program distributes a stake weighted amount of voting tokens to staked validator accounts. Validators then approve the vote by sending these tokens back to the account they were sent from. If at the end of the two week voting period the number of tokens in the account is greater than 67% of the total tokens distributed, the proposal passes and the program triggers a feature flag to enable the new minimum stake delegation in the next epoch.
Get Minimum Stake Delegation Instruction
In light of the potential modification of the minimum stake delegation based on the aforementioned vote, a new instruction to get the minimum stake delegation has been added to the program. This is needed as it is no longer a statically defined constant. This instruction is exposed in v1.14 via the command line interface (CLI), Web3.js, and the RPC method getMinimumStakeDelegation.
Undelegated Stakes Allowed Below Minimum
The stake program will now allow undelegated stake accounts to contain less than the minimum required stake delegation. This is needed now that the minimum stake delegation will change from 1 lamport if the minimum vote delegation vote passes.
Deactivate Delinquent Stake Instruction
A new instruction is added to the stake program that allows permissionless deactivation of delinquent stake on the network. Currently the only way to deactivate stake delegated to an abandoned vote account is to induce a hard fork or upon network restart. This new instruction can be invoked to force deactivate stake delegated to a vote account if the vote account has not voted in the last 5 epochs; about 15 days in real time.
Abandoned vote accounts cause stake to become unproductive as it will never be available for consensus. Unfortunately however, it continues to be counted towards the total effective stake. As a result, a proportional amount of productive stake is now needed to overcome this lingering unproductive stake; effectively increasing the total percentage of productive stake that is needed for consensus. Furthermore, and arguably more impactful, is the consequence that delinquent validators with enough stake still get leader slots. However because they are delinquent, their blocks will always be skipped, degrading performance of the entire network.
This new instruction allows network participants to clean up stake delegated to abandoned vote accounts. When the instruction is invoked, a second vote account is also required to be passed to prove that the chain has been active over the last 5 epochs. This is a security measure to prevent a very unlikely attack vector where a malicious actor could force the destaking of accounts if they are able to warp the chain ahead by 5 epochs.
Improvements to Caching
Version 1.14 also brings some general optimizations to reward distribution. The stake program now uses information stored in the bank as a stake cache to read and write to stake accounts. The stake cache allows reading and writing stake accounts to avoid the need to go all the way into the accounts database to access the stake accounts. This allows the program to avoid costly operations that access the hardware’s disk rather than their RAM. This optimization is showing a 30% reduction in reward distribution time.
The stake cache is updated at the same time a transaction updates the accounts database, so it remains synchronized with the accounts database at all times, even upon software update. Nevertheless, to avoid any potential issues with consensus due to a mismatch in the stakes calculation, the use of the stakes cache is feature gated.