Versioned Transaction and Address Lookup Table feature activation

[jstarry]

Problem

Support for versioned transactions and the new address lookup table feature hasn't been enabled on the mainnet-beta cluster yet. Enabling this feature is critical for allowing users to read / write more accounts in a single atomic transaction.

Rollout Plan

• Core Implementation
  • Add proposal for transactions v2 and address map program #17103
    • Amendment 1: Update address map proposal to improve dev experience #21576
    • Amendment 2: Migrate from address maps to address lookup tables #21634
  • Version transaction message and add new message format #18725
  • Store versioned transactions in the ledger, disabled by default #19139
  • Add runtime support for address table lookups #22223 (disabled until versioned_tx_message_enabled feature is activated)
  • Limit number of accounts that a transaction can lock #22201
  • Add address lookup table program #21616 (disabled until versioned_tx_message_enabled feature is activated)
    • Amendment 1: Add deactivation cooldown before address lookup tables can be closed #22011
    • Amendment 2: Prevent lookup tables from being closed during deactivation slot #22221
    • Amendment 3: Make payer and system program optional when extending lookup tables #23678
  • Fail tx sanitization when ix program id uses lookup table #25035
• Core Audit
  • Schedule audits (Scheduled for mid August)
  • Receive completed audits
  • Publish audits (https://github.com/solana-labs/security-audits)
    • OtterSec
    • Halborn
• RPC Support
  • Support versioned transactions in sendTransaction, simulateTransaction, getTransaction, and getBlock: Add RPC support for versioned transactions #22530 (v1.10)
  • Include lookup table keys in account keys list for parsedJson requests: RPC: include resolved keys from table lookups in parsed message response #27552 (v1.10)
  • getFeeForMessage: RPC: Support versioned txs in getFeeForMessage API #28217 (pending v1.10 release)
  • Improved unsupported transaction version error: RPC: Improve unsupported transaction error message #28249 (pending v1.10 release)
• Client Implementation
  • Support for versioned transactions
    • Rust
    • web3.js
      • Add versioned transaction classes: feat: add support for creating version 0 transactions #27142
      • Support versioned transaction responses: feat: update Connection to support versioned transactions #27068
      • Support creating transactions with lookup tables feat: implement message v0 compilation #27524
      • Add abstraction over transactions that use lookup tables feat: add TransactionMessage class #27526
    • Explorer: Explorer: Support displaying and inspecting versioned transactions #27825
  • Support for address lookup table instructions and state
    • RPC
      • State: Support jsonParsed address lookup table accounts #26723 (v1.14)
      • Instructions: Parse address-lookup-table instructions #27316 (v1.14)
    • Rust
    • web3.js
      • Instructions: Address Lookup Table Program Instruction Web3 Bindings #26469
      • State: feat: add getAddressLookupTable method to Connection #27127
    • Explorer
      • Instruction type: Explorer: Display address lookup table instruction type #27106
      • Instruction details
      • State: Explorer: Add details page for address lookup table accounts #27133
    • Wallet Adapter
      • Interface: Add versioned transaction methods to adapter interface anza-xyz/wallet-adapter#558
      • Example: Add versioned tx sending components to example app anza-xyz/wallet-adapter#567
      • Test Wallet: Turn fake wallet adapter into a burner wallet adapter anza-xyz/wallet-adapter#569
    • Mobile Wallet Adapter: feat: teach mobile-wallet-adapter to handle versioned transactions solana-mobile/mobile-wallet-adapter#254
  • CLI commands for creating and updating lookup tables: cli: Add subcommands for address lookup tables #27123
• Guides
  • Exchange Guide: docs: Add versioned tx info to exchange integration guide #27564
  • Developers Guide: [docs] versioned transactions and lookup tables #28060
  • Wallet Guide: docs: Add a wallet integration guide #25863
• Activate max_tx_account_locks feature
  • Testnet
  • Devnet
  • Mainnet-Beta
• Activate require_static_program_ids_in_transaction: Feature Gate: Require static program ids in transactions #25034
  • Testnet
  • Devnet
  • Mainnet-Beta
• Activate versioned_tx_message_enabled: Feature Gate: Versioned Transactions and Address Lookup Tables #24047
  • Testnet
  • Devnet
  • Mainnet-Beta
• Activate increase_tx_account_lock_limit: Feature Gate: Increase transaction account lock limit #27241
  • Testnet
  • Devnet
  • Mainnet-Beta
• Activate loosen_cpi_size_restriction: Feature Gate: Loosen CPI size limit restriction #26641
  • Testnet
  • Devnet
  • Mainnet-Beta

[staccDOTsol]

Wen mainnet-beta?

got here via https://github.com/staccDOTsol/address-lookup-table-multi-swap

kidding lol wp

[a-broz]

Any update on this being merged ?

[jstarry]

The changes are merged but guides are still in progress. We are targeting a launch at the end of September assuming that all parties have enough time to prepare.

[Broever101]

Is there any demo of using address lookup table and version transaction ?

This might help a little
https://medium.com/@antematterio/how-to-use-address-lookup-tables-in-solana-e2fe42dcc101

[pindaroso]

@jstarry Just checking in. Is this on mainnet? Thanks!

[jstarry]

Targeting Oct 7th for activation

[Arrowana]

Note, activation tomorrow but latest cli does not have #27123 in solana-cli 1.14.3

[staccDOTsol]

Note, Lfg. https://twitter.com/staccoverflow/status/1577917150425235461?s=46&t=mfi-ZbpDnc34scupUFCtYQ

[boucheravi]

still on for a 7th october activation? have heard some rumors of the update being paused for now

[jstarry]

Pushing back one more epoch to avoid activating on the weekend in case any service get disrupted due to the new transaction version. So the new date is Monday, Oct 10th.

[boucheravi]

thanks for the update!

[staccDOTsol]

one

more

epoch

[exp0nge]

Have there been noticeable getBlock perf. hits with this or did a new index get added that needs to be added to get the same perf as prior to activation?

[bmeeder22]

Did this ever get activated?

[a26nine]

Did this ever get activated?

Yes, it did. A few weeks ago...

[omarkilani]

Hi @jstarry,

Just wondering if I'm understanding this correctly, but if an ALT is deactivated and closed, it seems to mean that a message which references that ALT can no longer load any addresses belonging to that ALT?

[jstarry]

Hi @jstarry,

Just wondering if I'm understanding this correctly, but if an ALT is deactivated and closed, it seems to mean that a message which references that ALT can no longer load any addresses belonging to that ALT?

Yeah, that's correct.

[statikdev]

Hi @jstarry,

Just wondering if I'm understanding this correctly, but if an ALT is deactivated and closed, it seems to mean that a message which references that ALT can no longer load any addresses belonging to that ALT?

Yeah, that's correct.

If an account referenced in the ALT is no longer accessible, that would cause history to be lost from running getSignaturesForAddress or trying to associate that account to the transaction, right?

What is the reason for allowing closing of an ALT?

[CriesofCarrots]

No, there shouldn't be any history lost. The data supporting getSignaturesForAddress and other RPC endpoints gets stored in rocksdb when the transaction is processed, and duplicated to bigtable from there.

[omarkilani]

No, there shouldn't be any history lost. The data supporting getSignaturesForAddress and other RPC endpoints gets stored in rocksdb when the transaction is processed, and duplicated to bigtable from there.

Hey @CriesofCarrots , does this mean loadedAddresses from getTransaction still returns the right data even when the ALT account is closed?

[CriesofCarrots]

Hey @CriesofCarrots , does this mean loadedAddresses from getTransaction still returns the right data even when the ALT account is closed?

Yes, that's correct.

[omarkilani]

Hey @CriesofCarrots , does this mean loadedAddresses from getTransaction still returns the right data even when the ALT account is closed?

Yes, that's correct.

Awesome!

Thanks for your quick response!

[statikdev]

No, there shouldn't be any history lost. The data supporting getSignaturesForAddress and other RPC endpoints gets stored in rocksdb when the transaction is processed, and duplicated to bigtable from there.

👍 .

When walking backwards through transactions, if the ALT is not accessible, what would be the best way to find a referenced account?

EDIT: Disregard. Outdated as I wrote it and submitted without seeing the other comments..

[a26nine]

Is there any demo of using address lookup table and version transaction ?

This might help a little https://medium.com/@antematterio/how-to-use-address-lookup-tables-in-solana-e2fe42dcc101

Any example to use to create the version transaction using PDA ?

https://blog.a26nine.dev/address-lookup-tables-and-versioned-transactions-on-solana