-
Notifications
You must be signed in to change notification settings - Fork 79
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
SIMD-XXXX: Disable partitioned rent collection
- Loading branch information
Showing
1 changed file
with
78 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
--- | ||
simd: 'XXXX' | ||
title: Disable Partitioned Rent Updates | ||
authors: Justin Starry (Anza) | ||
category: Standard | ||
type: Core | ||
status: Draft | ||
created: 2024-09-24 | ||
feature: (fill in with feature tracking issues once accepted) | ||
--- | ||
|
||
## Summary | ||
|
||
Partitioned rent collection should be removed since it will no longer be useful | ||
after rent collection is disabled by | ||
https://github.com/solana-labs/solana/issues/33946 (SIMD-0084) and account | ||
rewrites are disabled by https://github.com/solana-labs/solana/issues/26599. | ||
|
||
## Motivation | ||
|
||
Since partitioned rent collection is no longer necessary for collecting rent or | ||
updating the account rent epoch field, it should be removed to speed up block | ||
production and block replay. | ||
|
||
## New Terminology | ||
|
||
NA | ||
|
||
## Detailed Design | ||
|
||
The reason that partitioned rent collection was not entirely disabled by earlier | ||
features is because it was desired that any pre-existing rent-paying account | ||
that becomes rent-exempt should have its rent epoch field set to the marker | ||
value of `u64::MAX`. This desired outcome can be achieved in a much more | ||
efficient manner without the need for loading every account once per epoch in | ||
partitioned rent collection. | ||
|
||
Disabling partitioned rent collection is very straightforward. Partitioned rent | ||
collection is initiated during bank freezing and can simply be not performed if | ||
a feature gate is activated. | ||
|
||
Retaining the behavior of updating the rent epoch field for newly rent exempt | ||
accounts can be done by adjusting the behavior of existing transaction rent | ||
checks. Currently, at the end of transaction processing, each writable account | ||
is checked for rent exemption to ensure that no accounts can be created as | ||
rent-paying. Those checks MUST be modified to additionally set the rent epoch | ||
to the marker value of `u64::MAX` if a pre-existing rent-paying account becomes | ||
rent exempt (note that this can only happen if an account is writable). | ||
|
||
Currently, new sysvars, builtins, and precompiles are all created with an | ||
initial rent epoch of `0` rather than the marker value of `u64::MAX`. So this | ||
proposal REQUIRES all new sysvars, builtins, and precompiles to be created with | ||
an initial rent epoch of `u64::MAX` to ensure that they are correctly marked as | ||
rent exempt. | ||
|
||
## Alternatives Considered | ||
|
||
NA | ||
|
||
## Impact | ||
|
||
Improved block processing performance by removing the need to load all accounts | ||
once per epoch for no good reason. Note that the epoch accounts hash calculation | ||
similarly loads all accounts once per epoch but serves the important role of | ||
ensuring that all validators have the same set of account state. | ||
|
||
## Security Considerations | ||
|
||
Rent related code changes often come along with a lot of edge cases to consider | ||
so changes should be made carefully to avoid introducing any bugs. | ||
|
||
## Drawbacks *(Optional)* | ||
|
||
Why should we not do this? | ||
|
||
## Backwards Compatibility *(Optional)* | ||
|
||
Changes require feature gates for activation to avoid any backwards incompatiblity |