|
| 1 | +--- |
| 2 | +simd: '0183' |
| 3 | +title: Skip Rent Rewrites |
| 4 | +authors: |
| 5 | + - brooks@anza.xyz |
| 6 | +category: Standard |
| 7 | +type: Core |
| 8 | +status: Draft |
| 9 | +created: 2024-10-04 |
| 10 | +feature: https://github.com/solana-labs/solana/issues/26599 |
| 11 | +--- |
| 12 | + |
| 13 | +## Summary |
| 14 | + |
| 15 | +Do not rewrite accounts *that are unchanged* by rent collection. |
| 16 | + |
| 17 | +## Motivation |
| 18 | + |
| 19 | +Rent collection checks every account at least once per epoch. This process |
| 20 | +loads *and stores* accounts, regardless if the account has actually changed or |
| 21 | +not. All accounts now must be rent-exempt, and there are zero rent-paying |
| 22 | +accounts on mainnet-beta. Thus, almost every account stored due to rent |
| 23 | +collection is unchanged, and storing unchanged accounts is useless work. |
| 24 | + |
| 25 | +Worse, storing accounts incurs all the downstream costs on the accounts |
| 26 | +database: computing the various accounts hashes on extra accounts unnecessarily, |
| 27 | +tracking/cleaning/purging the new and old versions of accounts, plus it bloats |
| 28 | +the incremental snapshots with accounts that haven't meaningfully changed. |
| 29 | + |
| 30 | +## Alternatives Considered |
| 31 | + |
| 32 | +We could remove rent collection entirely, and that is already planned |
| 33 | +(see SIMD-0084). Skipping rewrites is a smaller, less complex change, which |
| 34 | +can allow rollout and activation sooner. |
| 35 | + |
| 36 | +## New Terminology |
| 37 | + |
| 38 | +"Skipping rewrites" means to not store accounts that are unchanged by rent |
| 39 | +collection. |
| 40 | + |
| 41 | +## Detailed Design |
| 42 | + |
| 43 | +If rent collection has *not* changed an account, the account must not be |
| 44 | +stored/written back in that slot. |
| 45 | + |
| 46 | +An important note, rent collection updates an account's `rent epoch` in addition |
| 47 | +to its balance. If rent collection does not collect rent (i.e. the account's |
| 48 | +balance is unchanged), but *does* change the account's `rent epoch`, the |
| 49 | +account must still be stored. |
| 50 | + |
| 51 | +To state another consequence explicitly, since these accounts will not be |
| 52 | +rewritten, they will no longer be part of the accounts delta hash nor the |
| 53 | +incremental accounts hash. |
| 54 | + |
| 55 | +## Impact |
| 56 | + |
| 57 | +Validators will see performance improvements: |
| 58 | + |
| 59 | +* Fewer accounts will need to be stored per slot. |
| 60 | +* Fewer accounts will need to be hashed for the various accounts hashes. |
| 61 | +* Fewer accounts will need to be included in incremental snapshots. |
| 62 | + |
| 63 | +## Security Considerations |
| 64 | + |
| 65 | +Having all accounts rewritten due to rent collection results in all accounts |
| 66 | +being included in at least one bank hash per epoch. Since the bank hash is |
| 67 | +part of what is voted on for consensus, this means every account is verified by |
| 68 | +the network at least once per epoch. |
| 69 | + |
| 70 | +By skipping rewrites, we lose this security property. This is OK because the |
| 71 | +Epoch Accounts Hash (EAH) was added to directly address this issue. See the |
| 72 | +[EAH proposal](https://docs.solanalabs.com/implemented-proposals/epoch_accounts_hash) |
| 73 | +for more information. |
0 commit comments