バージョン付きトランザクション

Solanaは3つのトランザクションフォーマットをサポートしています：legacy、v0、v1。それぞれについて、ワイヤー上のバイト配置、アカウントの参照方法、リソース制限の出所という3つの観点から説明します。

フォーマット比較

ジャンプ先：Legacy · v0 · v1

Legacyフォーマット

オリジナルのフォーマットであり、ほとんどのツールでいまだにデフォルトとして使用されています。バージョンプレフィックスは一切なく、トランザクションの最初のバイトはシグネチャ配列のcompact-u16カウント、メッセージの最初のバイトはnum_required_signaturesであり、その最上位ビットは常に未設定です。

Legacyワイヤーレイアウト

可変長配列はすべてcompact-u16長プレフィックスが付きます：値0〜127は1バイト、より大きい値は2〜3バイトです。instruction単位のレイアウトとサイズ計算の例については、トランザクションバイナリフォーマットを参照してください。

Legacyのアカウント

すべてのアカウントはaccount_keys内に32バイトの完全な公開鍵として書き込まれ、instructionsは1バイトのインデックスでその配列を参照します。トランザクションに明示的に記載されていないアカウントを参照する方法はなく、これがlegacyトランザクションを1,232バイトを使い切る前におよそ32アカウントに制限する要因です。

Legacyのリソース制限

コンピュートユニット制限、ロード済みアカウントデータサイズ制限、ヒープサイズ、優先手数料はすべて、トランザクションにComputeBudgetプログラムのinstructionsを含めることでリクエストされます。それぞれがinstructionスロットを1つと150コンピュートユニットを消費します。省略しても安全です：ランタイムはデフォルト値（instruction当たり200,000 CU、上限1.4M、データサイズ制限64 MiB、ヒープ32 KiB、優先手数料ゼロ）にフォールバックします。

V0フォーマット

v0はlegacyメッセージに2つの要素を加えたものです：0x80バージョンプレフィックスバイトと、instructionsの後に追加されるaddress_table_lookups配列です。それ以前の部分はlegacyとバイト単位で同一です。

V0ワイヤーレイアウト

各アドレステーブルルックアップエントリには以下が含まれます:

アドレスルックアップテーブル

ALTは最大256個の公開鍵を保存するオンチェーンアカウントです。ALTを参照することで、トランザクションは32バイトの公開鍵の代わりに1バイトのインデックスを使用して追加のアカウントを含めることができ、アカウントごとのオーバーヘッドを大幅に削減します。

実行開始前のランタイムにおいて、validatorはすべてのALT参照を完全な公開鍵に解決します。解決されたアドレスは静的アカウントキーに追加され、完全なアカウントキーリストを形成します。ALTで解決されたアカウントは、静的アカウントと同じ順序に従います。書き込み可能なルックアップが読み取り専用ルックアップの前に配置されます。

v0のリソース制限

legacyから変更なし：ComputeBudget instructions、省略時のデフォルト値も同様。

V1フォーマット

v1はサイズ制限を4,096バイトに引き上げ、トランザクション設定を中心にメッセージを再構築します：リソース制限はComputeBudget instructionsから外れ、メッセージ自体の固定位置フィールドに移動します。これにより、ネットワークはinstructionリストをスキャン・デシリアライズせず、単一の固定オフセット読み取りでトランザクションを優先手数料でランク付けできます。

V1ワイヤーレイアウト

デコーダーを実装する際に注意すべきlegacyおよびv0との構造上の相違点が2つあります。カウントはcompact-u16ではなく固定幅のu8フィールドであること、そしてinstructionsは各instructionを連続して配置するのではなく、固定サイズのヘッダーをすべて先に並べ、その後に可変長ペイロードをすべて並べるという2つのランクに分割されることです。

v1のアカウント：アドレスルックアップテーブルなし

v1はALTサポートを意図的に廃止しています。64個の生アドレスは2,048バイトであり、4,096バイト制限内に十分収まるため、legacyと同様にすべてのアドレスをインラインで記述します。アプリケーションがルックアップテーブルに依存している場合、v1への移行はそれらのアドレスをインライン化することを意味します。

v1のリソース制限：トランザクション設定

設定はu32ビットマスクに続いて、そのビットが設定された各フィールドの固定幅値で構成されます：

未知のビットは拒否されます。メッセージは署名されているため、未認識の設定フィールドを暗黙的に破棄することはできません。

v1でのComputeBudget instructionsはno-op

v1トランザクションはComputeBudget instructionsを拒否しません — 設定においては無視されます。これらは引き続き成功したno-opとして実行され、150コンピュートユニットと64あるinstructionスロットのうちの1つを消費しますが、バジェットには何の影響も与えません。v1トランザクションを構築する際はこれらを取り除き、v1トランザクションを読み取る際はスキャンを止めてください：値はメッセージ設定に格納されています。

設定フィールドは明示的に指定する必要があります

送信者にとって最も重要な動作上の変更点：legacyおよびv0とは異なり、v1トランザクションはコンピュートユニット制限とロード済みアカウントデータサイズ制限を明示的に設定しなければならず、設定しない場合トランザクションは失敗します。

推奨されるアプローチは、両方の制限を最大値にして一度シミュレーションを実行し、返されたunitsConsumedとloadedAccountsDataSizeを設定に書き戻すことです。データサイズは余裕を持たせるために次の32 KiBページに切り上げてください（ブロックコストモデルは32 KiBページ単位で課金されるため、次のページ境界未満の余裕はコストがかかりません）。

v1への移行準備

v1はトランザクションの読み取りも変更します。送信だけではありません。v1が有効化されると、オプトインせずにgetTransactionやgetBlockを呼び出すクライアントはv1トランザクションで失敗し始めます：

• getTransactionおよびgetBlockにmaxSupportedTransactionVersion: 1 — 文字列"1"ではなくJSON整数の1 — を渡してください。0を渡すとパラメーターを省略した場合と同様にv1トランザクションで失敗します。v0のロールアウト時にコードベースを更新していても、値を変更する必要があります。
• getTransactionはv1トランザクションに対してエラー-32015で失敗し、getBlockレスポンスに1つでもv1トランザクションがあると、同じエラーでレスポンス全体が失敗します — 部分的な結果は返されません。
• blockSubscribeはblock: nullを返して進行を停止するため、これを空のブロックとして読み取るコンシューマーは最初のv1 slot以降から静かに遅延します。
• getSignaturesForAddressはトランザクション本体を検査しないため、v1のシグネチャは通常通り一覧表示されます。
• オプトイン済みのレスポンスには、v1トランザクションのメッセージにtransactionConfigオブジェクトが含まれます（legacyおよびv0では完全に省略されます）。ComputeBudget instructionsをスキャンして優先手数料やコンピュート制限を導出するパイプラインは、すべてのv1トランザクションに対してゼロを静かに報告します。
• クライアント側でトランザクションをデコードする場合、および1,232バイトを超えるトランザクションのsendTransaction/simulateTransactionにはencoding: 'base64'を使用してください — base58エンコーディングは旧来のサイズ上限のままです。
• クライアントライブラリのサポートには最新バージョンが必要です：@solana/kit 8.0以降、Agave 4.2.x世代のRustクレート、またはweb3.js v3。web3.js v1は1.99.0以降でv1を読み取れますが、構築または送信はできません。

クライアントライブラリのサポート、ストリーミング（Geyser/gRPC）のバージョン検出、シミュレーション動作を含む完全な移行ガイドについては、トランザクションフォーマットv1アップグレードページを参照してください。