ALT ✋🏻 — Learn the basics of Address LookUp Tables!
Welcome to our comprehensive guide covering the essentials of Address Lookup Tables (ALTs)! This tutorial is tailored to quickly familiarize you with the powerful features and capabilities of ALTs, with a special focus on their use in Rust and the Anchor Framework.
The code for this guide can be found in this repository. It’s advisable to follow along and run the examples locally to get a better grasp of Instruction Introspection.
Introduction to Address Lookup Table
The Solana blockchain, like any blockchain system, operates within certain technical limits. A key constraint is the maximum packet size that Solana’s validators can process: 1280 bytes, which matches the minimum transmission unit of IPv6. After accounting for the necessary headers, this restriction leaves only 1232 bytes for the payload, effectively capping the size of a transaction on the Solana network.
Address Lookup Tables (ALTs) were developed as a solution to these limitations. As detailed the following proposal, ALTs introduce a more efficient approach. Instead of storing full addresses within the transaction message, ALTs allow these addresses to be referenced just in the form of an index. This method transforms a standard 32-byte address into a compact 1-byte index value since accounts are referenced using a u8 index.
This breakthrough expands the transaction capacity, enabling a substantial increase in the number of addresses per transaction — soaring from the existing limit of 32 up to an impressive 256!”
Versioned Transactions — v0
The Solana runtime supports two transaction versions:
legacy- older transaction format with no additional benefit0- added support for Address Lookup Tables
The upgrade from the legacy transaction is marked by two upgrade:
Support for Address Lookup Tables
Each Address Lookup Table within the system consists of three distinct components:
- Account Key (u8): A unique identifier for each account.
- Writable Indexes: A compact array comprising indexes of writable account addresses.
- Read-Only Indexes: A compact array comprising indexes of read-only account addresses
In contrast to legacy transactions, where only the compact array of accounts included in the message is utilized, v0 transactions employ both the compact array of accounts in the message and indexes from the lookup table.
Introduction of a ‘Version’ Identifier:
This identifier is critical as it assists clients in determining the appropriate structure for the accurate deserialization of transactions.
Additionally, this update prompts users of older RPC methods to encounter error messages indicating the necessity for an upgrade to their methods to be compatible with the new transaction format.
Application for Address Lookup Table
Transaction Optimization
The compression obtained by using ALT significantly optimizes on-chain storage, as it consolidates all addresses into one account. This approach not only structures data handling and access more efficiently but also reduces costs. Smaller transaction sizes mean less network bandwidth usage, leading to smaller blocks resulting in substantial gas fee savings, as more operations can be bundled into fewer transactions.
Enhanced Atomicity
In scenarios where multiple accounts are involved in a transaction, maintaining atomicity is vital for data consistency. ALTs provide an elegant solution ensuring that all instruction within a transaction are executed in one indivisible operation, maintaining the integrity of the transaction.
Improved Metadata Handling and Easy Appending:
The inclusion of resolved addresses from an ALT in the transaction metadata significantly streamlines referencing since this eliminates the need for clients to make repeated RPC calls to retrieve all accounts involved in a transaction enhancing efficiency.
Live Example: building out all the instruction for ALT
In this section, we’ll explore a practical example on how to use all the instruction contained in the solana_address_lookup_table_program in Anchor
Create Address Lookup Table
The create_lookup_table instruction create an address lookup table account and returns the instruction and the table account’s derived address. As you can see the derived addess for this table account involves combining the authority key, the payer key, and the recent slot
ALTs are made with recent_slot as part of the "seeds" because if it 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 deactivation is no longer in the slot hashes sysvar.
NOTE 1: This instruction required the authority to be a signer until v1.12. Now the authority can just be passed in as AccountInfo.
NOTE 2: Address lookup tables can be created with either a v0 transaction or a legacy transaction. But the Solana runtime can only retrieve and handle the additional addresses within a lookup table while using
You can find the tests for this function here!
Extend Address Lookup Table
The extend_lookup_table instruction extend an address lookup table with new addresses. Once these addresses have been inserted into the table, and stored on chain, you will be able to utilize the Address Lookup Table in future transactions.
Due to the same memory limits of legacy transactions, any transaction used to extend an Address Lookup Table is also limited in how many addresses can be added at a time. Because of this, you will need to use multiple transactions to extend any table with more addresses (~20) that can fit within a single transaction's memory limits.
NOTE: payer and system program accounts are only required if the lookup table account requires additional lamports to cover the rent-exempt balance after being extended.
You can find the tests for this function here!
Freeze Address Lookup Table
The freeze_lookup_table instruction permanently freeze an address lookup table so that it can never be closed or extended again, making it immutable.
NOTE: Empty lookup tables cannot be frozen.
You can find the tests for this function here!
Deactivate Address Lookup Table
The deactivate_lookup_table instruction deactivates an address lookup table so that it cannot be extended again and will be unusable and eligible for closure after a short amount of time.
You can find the tests for this function here!
Close Address Lookup Table
The close_lookup_table instruction closes an address lookup table account. The account will be deallocated and the lamports will be drained to the recipient address.
Congratulations! You have now the capabilities to release the Power of ALTs in your Smart Contract! I hope this tutorial has been helpful and that you learned something insightful!
A special thanks to Richard that explained me this concept for the first time and to the Web3 Builder Alliance Institute that always teaches me cutting edge concept on Solana.
If you want to follow my journey and you don’t want to miss out my next tutorial, follow me on Twitter!
