Wallet Roundtable 5/18/2022

transaction_changes.md

Change 1: Transaction Prioritization

• From v1.10.14 onwards, validators will try to consume transactions in order of priority which is based on the prioritization fee paid per compute unit.
• In order to optimize priority / fee paid, transaction should set its compute unit limit as low as possible because leftover compute units are not refunded.

Runtime Features

tx_wide_compute_cap (Implemented in v1.9.7, v1.10.0) (Activated on Devnet & Testnet)

• Updates compute unit limits to be transaction-wide rather than reset to 200k compute units per transaction instruction. Sets the maximum transaction compute unit limit to 1.4M compute units. The default compute unit limit is also set to 1.4M compute units to avoid breaking existing transactions which rely on consuming more than 200k compute units by spreading compute across multiple instructions.
• Adds the ComputeBudget::RequestUnits instruction which has two parameters:
  • Compute unit limit
  • Prioritization fee (lamports)

add_set_compute_unit_price_ix (Implemented in v1.10.14) (Unactivated)

• Adds two new ComputeBudget program instructions:
  • ComputeBudgetInstruction::SetComputeUnitLimit
    • Sets the compute unit limit for a transaction (can result in a higher or lower limit relative to the default compute unit limit)
  • ComputeBudgetInstruction::SetComputeUnitPrice
    • Sets a price per compute unit in "micro-lamports" (10^6 micro-lamports per lamport). Higher price will increase transaction prioritization. The price will be multiplied by the transaction compute unit limit to calculate the transaction's prioritization fee.

(WIP) Integration Guide

1. Either apps or wallets (discussion) should add the SetComputeUnitLimit instruction. We will be adding the consumed number of compute units to the transaction simulation metadata response, but that has not been started yet.
2. Wallets should probably prompt the user to pick a compute unit price during times of congestion to increase prioritization. We will likely be adding a new RPC endpoint to get the average compute unit price in recently confirmed blocks.

Change 2: Versioned Transactions

• Will be enabled when mainnet migrates fully to v1.10
• The current Solana transaction format doesn't include a version number. It's now considered a "legacy" transaction as opposed to the new "versioned" transactions.
• The first versioned transaction has version 0 and will support address lookup tables which allows transactions to succinctly lock many more accounts within the 1232 byte constraint on serialized transaction size.

Runtime Features

versioned_tx_message_enabled (Implemented in v1.10.3) (Activated on Devnet & Testnet)

• Adds a version number to transactions
• The first versioned transaction (v0) supports a list of address lookup table entries which can be used to lock more accounts per transaction by using fewer bytes in a serialized transaction (limited to 1232 bytes).
• Signer accounts cannot be looked up from an address lookup table. They must be in the transaction's static account key list.
• Introduces the AddressLookupTable program which can be used to write addresses to an on-chain lookup table account. When the runtime processes a v0 transaction, its address lookup table entries will be resolved with the on-chain addresses before processing. Programs will not be able to tell if an account's address was included statically in the transaction or dynamically loaded. The only change is that they will be able to receive longer lists of accounts than before.

max_tx_account_locks (Implemented in v1.9.3) (Activated on Devnet & Testnet)

• Limits the number of accounts that a transaction can lock to 64

require_static_program_ids_in_transaction (Implemented in v1.10.13) (Unactivated)

• Program ids invoked by transaction instructions cannot be looked up from an address lookup table. They must be in the transaction's static account key list.

(WIP) Integration Guide

1. Clients that request blocks with versioned transactions must specify a high enough "maxSupportedTransactionVersion" to avoid incorrectly handling transaction details for newer versions.
2. Client SDKs will need to support serializing and deserializing versioned transactions. Only the Rust SDK supports versioned transactions at this time. The Rust SDK will serve as the reference implementation, the TypeScript web3 SDK will be next, and we will be reaching out to other community run SDKs to add support as well.
3. Versioned transactions that use address lookup tables can be simulated. We will add the resolved addresses from the lookup tables in the metadata response, but this hasn't been implemented yet.
4. Versioned transactions with address lookup tables can be "decompressed" with client SDK support. Client SDK's should batch requests address lookup table account data and use them to decompress the full account list of the transaction.

@jstarry thanks for putting this together, they both sound very cool!

A few questions:

1. Where can we see the current version that the Solana Mainnet is running? And how can we test what features are released (I saw there was some tool to test feature gating)? It would be sweet to have this on a website somewhere.
2. "Only the Rust SDK supports versioned transactions at this time." — Can you share a link to where this parses versioned transactions? We have built our own tx parser internally and could open source it.
3. Do you have an estimated timeline on both of those features?