Updates to the address lookup table proposal (#22269)
This commit is contained in:
parent
9665da9d0b
commit
ca5591bfa0
|
@ -53,11 +53,16 @@ store up to 256 addresses each. In addition to stored addresses, address table
|
|||
accounts also tracks various metadata explained below.
|
||||
|
||||
```rust
|
||||
/// The maximum number of addresses that a lookup table can hold
|
||||
pub const LOOKUP_TABLE_MAX_ADDRESSES: usize = 256;
|
||||
|
||||
/// The serialized size of lookup table metadata
|
||||
pub const LOOKUP_TABLE_META_SIZE: usize = 56;
|
||||
|
||||
pub struct LookupTableMeta {
|
||||
/// The slot used to derive the table's address. The table cannot
|
||||
/// be closed until the derivation slot is no longer "recent"
|
||||
/// (not accessible in the `SlotHashes` sysvar).
|
||||
pub derivation_slot: Slot,
|
||||
/// Lookup tables cannot be closed until the deactivation slot is
|
||||
/// no longer "recent" (not accessible in the `SlotHashes` sysvar).
|
||||
pub ddeactivation_slot: Slot,
|
||||
/// The slot that the table was last extended. Address tables may
|
||||
/// only be used to lookup addresses that were extended before
|
||||
/// the current bank's slot.
|
||||
|
@ -67,6 +72,8 @@ pub struct LookupTableMeta {
|
|||
pub last_extended_slot_start_index: u8,
|
||||
/// Authority address which must sign for each modification.
|
||||
pub authority: Option<Pubkey>,
|
||||
// Padding to keep addresses 8-byte aligned
|
||||
pub _padding: u16,
|
||||
// Raw list of addresses follows this serialized structure in
|
||||
// the account's data, starting from `LOOKUP_TABLE_META_SIZE`.
|
||||
}
|
||||
|
@ -88,11 +95,17 @@ pub struct BufferMeta {
|
|||
|
||||
#### Cleanup
|
||||
|
||||
Once an address lookup table is no longer needed, it can be closed
|
||||
and have its rent balance reclaimed. Address lookup tables may not be recreated
|
||||
Once an address lookup table is no longer needed, it can be deactivated and closed
|
||||
to have its rent balance reclaimed. Address lookup tables may not be recreated
|
||||
at the same address because each new lookup table must be initialized at an address
|
||||
derived from a recent slot.
|
||||
|
||||
Address lookup tables can be deactivated at any time but can continue to be used
|
||||
by transactions until the deactivation slot is no longer present in the slot hashes
|
||||
sysvar. This cool-down period ensures that in-flight transactions cannot be
|
||||
censored and that address lookup tables cannot be closed and recreated for the same
|
||||
slot.
|
||||
|
||||
#### Cost
|
||||
|
||||
Since address lookups require extra overhead during transaction processing,
|
||||
|
@ -226,7 +239,7 @@ If an address lookup table can be closed and re-initialized with new addresses,
|
|||
any client which is unaware of the change could inadvertently lookup unexpected
|
||||
addresses. To avoid this, all address lookup tables must be initialized at an
|
||||
address derived from a recent slot and they cannot be closed until the slot
|
||||
used for derivation is no longer "recent."
|
||||
used for deactivation is no longer in the slot hashes sysvar.
|
||||
|
||||
### Resource consumption
|
||||
|
||||
|
@ -259,7 +272,8 @@ similar to sysvar accounts.
|
|||
For this reason, special handling should be given to address lookup tables.
|
||||
When an address lookup table is used to lookup addresses for a transaction,
|
||||
it can be loaded without waiting for a read lock. To avoid race conditions,
|
||||
only the addresses appended in previous blocks can be used for lookups.
|
||||
only the addresses appended in previous blocks can be used for lookups and
|
||||
deactivation requires a cool-down period.
|
||||
|
||||
### Duplicate accounts
|
||||
|
||||
|
|
Loading…
Reference in New Issue