Skip to content
This repository has been archived by the owner on Jan 22, 2025. It is now read-only.

Add deactivation cooldown before address lookup tables can be closed #22011

Merged
merged 1 commit into from
Dec 20, 2021

Conversation

jstarry
Copy link
Contributor

@jstarry jstarry commented Dec 19, 2021

Problem

Address lookup tables will be used to load transaction addresses without taking a read lock on the address lookup table account so they cannot be closed in a way that would affect in-progress address loading.

Summary of Changes

  • Change derivation_slot field to deactivation_slot to track when an address table has been deactivated long enough that it can be closed.
  • Don't allow changes to an address lookup table account if it has been deactivated.

Fixes #

@jstarry jstarry added the v1.9 label Dec 19, 2021
@jstarry jstarry requested a review from joncinque December 19, 2021 20:55
@codecov
Copy link

codecov bot commented Dec 20, 2021

Codecov Report

Merging #22011 (55d6fd3) into master (301d585) will decrease coverage by 0.0%.
The diff coverage is 10.7%.

@@            Coverage Diff            @@
##           master   #22011     +/-   ##
=========================================
- Coverage    81.4%    81.3%   -0.1%     
=========================================
  Files         517      517             
  Lines      145470   145522     +52     
=========================================
- Hits       118430   118417     -13     
- Misses      27040    27105     +65     

Copy link
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good with just the one question. Is this leaning more heavily on the idea that there will be other storage mechanisms for these accounts? Also, does this implicitly mean that address lookup tables are immediately usable? Or will there be some runtime hook to ensure that new tables aren't used in the same slot? I don't totally understand why the address is derived from a slot now, or how it's used elsewhere.

/// # Account references
/// 0. `[WRITE]` Address lookup table account to deactivate
/// 1. `[SIGNER]` Current authority
DeactivateLookupTable,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just double-checking, this isn't being used yet, correct? If so, this reordering of instructions will break existing clients

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct!

@jstarry
Copy link
Contributor Author

jstarry commented Dec 20, 2021

Looks good with just the one question. Is this leaning more heavily on the idea that there will be other storage mechanisms for these accounts? Also, does this implicitly mean that address lookup tables are immediately usable? Or will there be some runtime hook to ensure that new tables aren't used in the same slot? I don't totally understand why the address is derived from a slot now, or how it's used elsewhere.

It's possible that we add an extra cache for these lookup tables but not required for the initial implementation.

Address table additions can be used in the following slot. The design allows the runtime to safely read address table accounts for transaction address table lookups without any locking. This part will be clearer in the next PR.

The address is derived from a slot so that it's not possible to recreate an address table account with different addresses.

@jstarry jstarry merged commit f5d1115 into solana-labs:master Dec 20, 2021
@jstarry jstarry deleted the address-table-deactivation branch December 20, 2021 23:33
mergify bot pushed a commit that referenced this pull request Dec 20, 2021
mergify bot added a commit that referenced this pull request Dec 21, 2021
@brooksprumo brooksprumo mentioned this pull request Jan 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants