SIMD-0329: Track Last Accessed Slot for Accounts #329

igor56D · 2025-08-01T22:40:30Z

No description provided.

proposals/0329-account-creation-slot.md

MaxResnick · 2025-10-14T17:09:56Z

proposals/0329-last-accessed-slot.md

+The additional 8 bytes per account may increase snapshot size if insufficient
+unused account metadata bytes are available. Currently, there are enough unused
+bytes (due to padding and deprecated fields) so this specific change shouldn't
+increase state size.
+


Lets try to use the existing unused rent field on accounts so we don't have to resize accounts with this change

Right, probably better to be more explicit here

MaxResnick · 2025-10-14T17:13:21Z

proposals/0329-last-accessed-slot.md

+6. **Feature Gate Activation**: This change is guarded by a feature gate. Upon
+   activation in a block at slot S, all existing accounts MUST have
+   `last_accessed_slot` initialized to S when loaded (e.g., from snapshot or
+   ledger). New accounts created after activation MUST initialize the field to
+   the current slot at creation time.
+


We can intitialize this when the account is write locked after the feature gate activates to amoritize the cost over time.

I'll change the wording here, it's unclear. The intention was to have pre-activation accounts lazily initialized to S when the value is first accessed.

though, I'd say this is mostly an implementation detail. Clients can choose how/when to update pre-activation accounts, the important detail is that the value should default to S. I'll clarify regardless

Writing the default value might need to be done over a whole epoch, similar to how rent collection used to be done.

And if the rent_epoch bytes are reused for this new field, then we can be in a situation where nodes disagree about the value for that field if we don't enforce an order of when accounts will be updated.

It's not clear from the current set of SIMDs, but will rent_epoch be completely deprecated / removed from consensus before this SIMD? If so, then we should be fine. If not, we'll probably need to do that deprecation with a separate SIMD.

@joncinque Correct me if I'm wrong, but isn't rent_epoch already removed from consensus? It's no longer in the accounts hash and it's hardcoded in the vm. cc @brooksprumo

Writing the default value might need to be done over a whole epoch, similar to how rent collection used to be done.

Discussed this offline: I assumed there already existing a migration path for account structure changes but that turned out to be wrong, so this will be more complicated than I expected. There should be a forthcoming SIMD for adding versioning to accounts, which will make this migration much more straightforward.

It's not clear from the current set of SIMDs, but will rent_epoch be completely deprecated / removed from consensus before this SIMD? If so, then we should be fine. If not, we'll probably need to do that deprecation with a separate SIMD.

I'm confused on this as well because there hasn't been an explicit deprecation SIMD, but it appears that for all intents and purposes rent_epoch has already been deprecated (stubbed out in the runtime and excluded from the lthash).

Ok great, I truly wasn't aware, but it sounds like rent_epoch has been totally deprecated.

Yep, rent_epoch is practically gone. The field exists in some agave/sdk structs, but the value itself is not under consensus.

joncinque

Looks good overall! Mostly small comments.

joncinque · 2025-10-14T20:29:57Z

proposals/0329-last-accessed-slot.md

+2. **Update on Write-Lock**: Each time a transaction that write-locks an
+   account is included in a block, that account's `last_accessed_slot` MUST be
+   set to the block's slot.


I can imagine this happening at three possible times:

before the transaction is processed

after the transaction is processed

at the end of the block

I imagine the best option is to write the value after the transaction is processed.

Also, does this change if the transaction was successful or not? It seems like we'll need to write the data even on failures, which is a bit different from normal transaction processing, where only lamports are deducted from the fee payer.

I can imagine this happening at three possible times:

This should be specified - agree that after the transaction is processed seems like the most natural place to do this.

Also, does this change if the transaction was successful or not? It seems like we'll need to write the data even on failures, which is a bit different from normal transaction processing, where only lamports are deducted from the fee payer.

This should definitely also be specified.

Will update the doc to specify this should be updated like most other account state: after successful execution. The reason to only update on successful execution is to allow more flexibility in the future rent payment system: e.g programs can determine how rent payments work rather than requiring the fee payer to always cover it.

tbh given this, it probably makes more sense to just rename this field to last_write_slot.

IMO we should update this field if-and-only-if the account is going to be stored. Aka when committing transactions.

joncinque · 2025-10-14T20:32:11Z

proposals/0329-last-accessed-slot.md

+9. **On-chain ABI exposure**: `last_accessed_slot` is runtime metadata only and
+   is NOT added to the on-chain `AccountInfo` ABI. It is not exposed to
+   programs, and no new syscalls are introduced by this SIMD. Any future
+   on-chain exposure (e.g., a syscall or ABI extension) will be proposed via a
+   separate SIMD and feature gate.


Makes sense! We could reuse the rent epoch that exists on the account info in ABIv1, but a syscall in ABIv2 (TBD) will likely be easier to add

joncinque · 2025-10-14T20:37:22Z

proposals/0329-last-accessed-slot.md

+5. **RPC and Client Exposure**: `last_accessed_slot` SHOULD be available
+   through relevant RPC endpoints that return account information, allowing
+   clients to access this metadata.


Seems reasonable, RPC will default rentEpoch to u64::MAX and add a new field for lastAccessedSlot when fetching or returning accounts.

For simulateTransaction, the lastAccessedSlot should probably be updated to the current slot.

joncinque · 2025-10-14T20:43:02Z

proposals/0329-last-accessed-slot.md

+6. **Feature Gate Activation**: This change is guarded by a feature gate. Upon
+   activation in a block at slot S, all existing accounts MUST have
+   `last_accessed_slot` initialized to S when loaded (e.g., from snapshot or
+   ledger). New accounts created after activation MUST initialize the field to
+   the current slot at creation time.
+


Writing the default value might need to be done over a whole epoch, similar to how rent collection used to be done.

And if the rent_epoch bytes are reused for this new field, then we can be in a situation where nodes disagree about the value for that field if we don't enforce an order of when accounts will be updated.

It's not clear from the current set of SIMDs, but will rent_epoch be completely deprecated / removed from consensus before this SIMD? If so, then we should be fine. If not, we'll probably need to do that deprecation with a separate SIMD.

ripatel-fd · 2025-10-16T14:22:38Z

proposals/0329-last-accessed-slot.md

+      lthash.append( account.owner )
+      lthash.append( account.pubkey )
+      lthash.append( account.last_accessed_slot )
+      return lthash.fini()


if we're changing the lthash anyways, let's also move account.data to the end of the account IMO (and introduce a hashing prefix)

Having account.data in the middle of the hash input was always broken

I agree. When/if 379 is accepted, this change should be included for v1 accounts.

ripatel-fd · 2025-10-16T14:25:03Z

proposals/0329-last-accessed-slot.md

+    values.
+
+8. **Accounts lattice hash update**: the lattice hash of an account must
+    include the `last_accessed_slot`:


It would be good to specify a migration mechanism here. Implementations will probably need to track which accounts have the last_accessed_slot field depending on whether lthash set removal is done with the old hash (safe) or new hash (probably also safe but more cryptographic concerns here). This sort of tracking has overhead

there's definitely more complexity in the migration than I originally thought due to the lack of account versioning. I believe one of the accountsdb people is working on a proposal to add a version field to the metadata that should make updates more straightforward.

Yeah, changing the per-account hash is non-trivial now that we have the accounts lt hash. See #319 (comment) for some more discussion.

ripatel-fd · 2025-10-16T14:26:44Z

Not opposed to the idea of adding metadata to accounts. But I'd wait until merging this proposal until we have another SIMD defining a use case for this new field.

igor56D · 2025-10-16T16:02:32Z

Not opposed to the idea of adding metadata to accounts. But I'd wait until merging this proposal until we have another SIMD defining a use case for this new field.

The rent mechanism described in SIMD-0344 (dynamic rent) will use the new field.

brooksprumo · 2025-10-20T14:52:23Z

proposals/0329-last-accessed-slot.md

+- Track `last_accessed_slot` for each account as part of the account's metadata.
+- Each time a transaction that write-locks an account is included in a block,
+  update that account's `last_accessed_slot` to the block's slot.


Can we rename accessed everywhere with either modified or updated?

IMO the word "accessed" also includes, read-only accesses, which we explicitly do not want to trigger an account update.

Additionally, can we rename "last" to either "most recent" or "latest"? IMO the word "last" can be ambiguous, whereas "most recent" and "latest" both resolve the ambiguity by having the notion of time ordering in their definitions.

brooksprumo · 2025-10-20T14:56:09Z

proposals/0329-last-accessed-slot.md

+4. **Initialization for Existing Accounts**: For accounts that exist before
+   activation of this feature, `last_accessed_slot` MUST be initialized to the
+   slot of the block that activates the feature.


Is there a reason why using feature activation slot is required here, versus something like slot 0?

The idea is that in the absence of exact write history, we default to a value that is guaranteed to be as or more recent than the true value. ie latest_write_slot >= actual_latest_write_slot.

That said, defaulting to 0 might be easier for the implementation. If higher level mechanisms (like rent) want to use the value, they can interpret 0 in whichever way makes sense in their context. What do you think?

brooksprumo · 2025-10-20T14:58:56Z

proposals/0329-last-accessed-slot.md

+The additional 8 bytes per account may increase snapshot size if insufficient
+unused account metadata bytes are available. Currently, there are enough unused
+bytes (due to padding and deprecated fields) so this specific change shouldn't
+increase state size.


IMO increasing the size of an account is a non-starter at the moment. We must repurpose the existing-and-obsolete rent_epoch field.

right, this is from an older version of the proposal. I've updated it to specifically replace the deprecated rent_epoch field.

brooksprumo · 2025-10-20T15:01:27Z

proposals/0329-last-accessed-slot.md

+- Each time a transaction that write-locks an account is included in a block,
+  update that account's `last_accessed_slot` to the block's slot.
+
+## Motivation


The motivation here in this section is quite sparse. Changing account format is an extremely invasive change, and should only be done when absolutely necessary. IMO the current motivation doesn't sufficiently indicate necessity, and so I would push back against this SIMD in its current form.

I suppose I should explicitly mention that this field is required for the dynamic rent mechanism described in SIMD-0344. I'll add that.

igor56D · 2025-10-20T23:07:40Z

Note: due to the lack of an account migration path, this SIMD depends on this proposal, which introduces a version field to accounts.

igor56D added 2 commits August 1, 2025 17:39

initial SIMD draft - track account creation slot

440e309

update simd ID to 0329

3239d36

igor56D force-pushed the account-creation-slot branch from f497894 to c27d3b0 Compare August 1, 2025 22:55

fix lint

e06bfba

igor56D force-pushed the account-creation-slot branch from c27d3b0 to e06bfba Compare August 1, 2025 22:57

github-actions bot mentioned this pull request Aug 4, 2025

Upstream Updates - Mon Aug 4 00:19:45 UTC 2025 smartcontractkit/chainlink-solana#1312

Open

igor56D changed the title ~~Track Account Creation Slot in Account Metadata~~ Track Account Access and Account Creation Slot Aug 11, 2025

igor56D changed the title ~~Track Account Access and Account Creation Slot~~ SIMD-0329: Track Account Access and Account Creation Slot Aug 11, 2025

update to include access tracking of pre-activation accounts

14acb30

igor56D force-pushed the account-creation-slot branch from 9ed6698 to 14acb30 Compare August 11, 2025 19:59

igor56D changed the title ~~SIMD-0329: Track Account Access and Account Creation Slot~~ SIMD-0329: Track Last Accessed Slot for Accounts Oct 7, 2025

distill proposal down to basic last_accessed_slot tracking

74f73f6

igor56D force-pushed the account-creation-slot branch from 313ccef to 74f73f6 Compare October 7, 2025 21:47

clarify that SVM ABI won't change

aac01ad

igor56D marked this pull request as ready for review October 7, 2025 23:57

remove fluff

ca30bbc

MaxResnick suggested changes Oct 14, 2025

View reviewed changes

joncinque reviewed Oct 14, 2025

View reviewed changes

ripatel-fd reviewed Oct 16, 2025

View reviewed changes

brooksprumo reviewed Oct 20, 2025

View reviewed changes

respond to feedback

4c89730

SIMD-0329: Track Last Accessed Slot for Accounts #329

Are you sure you want to change the base?

SIMD-0329: Track Last Accessed Slot for Accounts #329

Conversation

igor56D commented Aug 1, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ripatel-fd Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ripatel-fd Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ripatel-fd commented Oct 16, 2025

Uh oh!

igor56D commented Oct 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ripatel-fd Oct 16, 2025 •

edited

Loading

ripatel-fd Oct 16, 2025 •

edited

Loading