Solana
准备好在生产环境中调用了吗?
免费套餐涵盖个人项目。按量付费,无需绑卡即可扩展。
Solana
免费套餐涵盖个人项目。按量付费,无需绑卡即可扩展。
Versioned transactions are the modern transaction format on Solana, introduced to lift a hard limit of the original layout. A legacy transaction lists every account it touches inline, and because a single transaction is capped at 1232 bytes, that inline list runs out of room quickly — a problem for DeFi routes and other composed instructions that reference dozens of accounts. A versioned (v0) transaction keeps the same instructions but adds support for Address Lookup Tables (ALTs): on-chain tables that store account addresses once, so the transaction can point at a table index instead of repeating a full 32-byte pubkey. That indirection lets one transaction reference far more accounts than a legacy message ever could, while staying under the byte limit.
Message carries a flat staticAccountKeys array. A MessageV0 keeps that array but adds addressTableLookups, letting the runtime resolve extra accounts from one or more ALTs at execution time.getTransaction and getBlock will reject a v0 transaction unless you pass maxSupportedTransactionVersion: 0. Omit it and you get a version error instead of the transaction.0 is the single non-legacy transaction version Solana supports, so maxSupportedTransactionVersion: 0 is the value you will always use.maxSupportedTransactionVersion: 0 to every getTransaction and getBlock call so v0 entries are returned instead of triggering a version error.getLatestBlockhash immediately before signing so the transaction does not expire while you assemble it.@solana/web3.js, solders, or the Rust/Go clients may not compile v0 messages at all — stay on a recent release before relying on versioned transactions.