Solana v1 トランザクションの解説：サイズ制限と互換性を損なう変更

Quicknode

2026年9月1日 — 読了時間10分

シェア

「お気に入り」として追加

開発者 Solana 上で複雑なアプリケーションを構築してきた開発者たちは、長年にわたりトランザクションのサイズ制限を回避する方法を模索してきました。v0ではアドレスルックアップテーブルが導入され、1,232バイトを超えずに、1つのトランザクションでより多くのアカウントを参照できるようになりました。最新のアップグレードではv1トランザクションが導入され、制限そのものが 3.3倍に引き上げられました。by

トランザクション v1 では、シリアライズされたトランザクションの最大サイズが 1,232 バイトから 4,096 バイトに引き上げられ、2026年9月上旬にリリースされる Agave v4.2 から有効になります。ゼロ知識証明（ZK）アプリ やマルチシグシステム、複雑な DeFi プリミティブを構築するチーム にとって、この追加の容量により、これまで必要とされていた一連の回避策が不要になります。

v1を採用していなくても、影響を受ける可能性がありますby 。Solana のデータを読み取るすべてのものが影響を受けます。v1トランザクションを送信したことがあるかどうかは関係ありません。

1,232バイトという制限はUDPに由来するものでした。Solana は数年前にトランザクションの取り込みをQUICに移行し、これによりその制約は解消されました。しかし、制限自体は残ったままでした。チーム では、トランザクションの分割やルックアップテーブルの構築を続け、もはや基盤となるトランスポートプロトコルと整合しない上限値に合わせてシステムを構築し続けていました。

この新しい制限は、ネットワーク上の制約に基づくものではありません。4,096バイトという値は、バリデーターのメモリページに整合しています。これにより、ZK証明、BLS署名方式、機密転送、オラクル価格更新リクエストに対応できるほか、バンドル方式を用いることなく、1つのトランザクションにより多くの命令を収めることが可能になります。また、64アカウントのセット全体をインラインで収めることができるため、v1ではアドレスルックアップテーブルが完全に廃止されています。

Solana v1トランザクションとは何ですか？

v1トランザクションとは、上限が4,096バイトの新しいSolana ワイヤ形式です。これは単に上限が引き上げられたv0ではなく、両者には以下の5つの違いがあります：

• バージョンバイト 0x81 オフセット0の位置にあるため、どのコンシューマーも1バイトだけでそのフォーマットを識別できる

• 署名は、メッセージの先頭ではなく、トランザクションの末尾に移動します

• 固定幅 u8 カウントはコンパクト-u16エンコーディングに置き換わる

• 命令ヘッダーはペイロードよりも前にグループ化されているため、境界を直接計算できる

• リソース制限がヘッダー構成マスクに反映される

アドレス検索テーブルは廃止されました

サポート v1では、アドレス検索テーブル用の領域が削除されました。現在、各アカウントは32バイトの完全な公開鍵としてインラインで伝送され、最大64個のアドレスのセットが2,048バイトを占めます。これは、単一の命令が追加される前の新しいエンベロープの半分のサイズに相当します。

Solana メインネット のトラフィック全体にわたってコストを測定しました。v0トランザクションの約62%が、少なくとも1つのルックアップテーブルを参照しています。これをv1に換算すると、その半数は420バイト未満のオーバーヘッドとなり、90%は1,400バイト未満となっています。複数のテーブルを参照して、それぞれ少数のアドレスを取得するトランザクションは、テーブルのオーバーヘッドが圧縮による削減効果を上回ったため、サイズが小さくなりました。

ルックアップテーブルを削除することで、バリデーターへのデータ取り込みも簡素化されます。v0 では、トランザクションがどのアカウントに影響を与えるかをバリデーターが把握する前に、状態に応じたテーブルの解決が強制されます。一方、v1 では、トランザクション自体に完全なアカウントセットが渡されるため、手数料や優先順位の計算がより早い段階で実行されます。

「エクストラ・バイト」で何が得られるのか

ペイロードの多いアプリケーションは、プルーフや命令データがアカウントスロットを消費することなくバイト数を消費するため、容量が増加します。一方、マルチベニュー・ルーティングや広範なプロトコル合成など、アカウントを多用するアプリケーションは、新しい容量の大部分を、以前はルックアップテーブルによって圧縮されていたアドレスの再インライン化に費やします。こうしたチーム にとって、64アカウントという上限が現在、制約条件となっており、v0のままにしておくことが妥当な選択となります。

v1で設定される制限はバイト数のみです。アカウント数は64、命令数は64、署名数は12のままです。

Solana のデータを読み込む際に何が問題になるのか

Solana のデータを読み取ったりインデックスを作成したりするアプリケーションは、クエリ対象のブロック内にv1トランザクションが初めて出現した時点で失敗します。先頭からトランザクションを読み取るコードは、レガシーおよびv0の署名が配置される位置にメッセージデータが到達してしまうため、長さのチェックでエラーを発生させるby のパーサーを修正することはできません。

getBlock および getTransaction は v1 トランザクションを拒否します

v1を宣言していない呼び出しサポート はエラーを返す -32015 そのトランザクションに接触した瞬間に、ブロック全体の読み取りが失敗します。インデクサやバックフィルジョブは、解析できないその1つのトランザクションをスキップするのではなく、停止します。設定 maxSupportedTransactionVersion: 1 両方の呼び出しにおいて、JSONの整数として 1. 文字列 "1" 失敗し、同様に 0, そのため、v0の展開期間中にv0のサポート を有効にしたコードについては、まだ対象外となっています。 getSignaturesForAddress トランザクション本体は検査されないため、これには影響を受けません。

次のコードがエラーになる：

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [402184291, { "encoding": "json" }]
}

同じ呼び出しですが、修正しました。base58では1,232バイトを超えるトランザクションをエンコードできないため、versionパラメータに加えてBase64も必要です：

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [
        402184291,
        {
            "encoding": "base64",
            "maxSupportedTransactionVersion": 1
        }
    ]
}

blockSubscribe の進行が止まる

blockSubscribe 放出する null そして、v1トランザクションに到達すると処理が停止し、捕捉すべきエラーも発生しません。エラー率に基づいて構築された監視機能は決して作動しないため、サブスクリプションは最初のv1スロットでスタックしたままになります。設定 maxSupportedTransactionVersion: 1 定期購読については、以下のように扱ってください ブロック: null 空のブロックではなく失敗として扱い、鮮度チェックを追加してください。そうしなければ、これを検出する手段が他にないからです。

ComputeBudgetのスキャン結果がゼロを返す

v1では、演算制限と優先度料金が命令からメッセージレベルの設定に移行しました。ComputeBudget命令をスキャンするインデクサーは、一致する項目が見つからず、どのレイヤーでもエラーを発生させることなく、すべてのダウンストリームデータセットにゼロを書き込みます。代わりに、トランザクション設定から制限値を読み取ってください。この設定は、オプトインされたレスポンスではメッセージ内に含まれますが、レガシーおよびv0では完全に欠落しています。設定されていないフィールドはそのまま返されます。 null:

"message": {
    "instructions": ["… no ComputeBudget instruction here …"],
    "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF",
    "transactionConfig": {
        "computeUnitLimit": 30000,
        "heapSize": null,
        "loadedAccountsDataSizeLimit": 200000,
        "priorityFee": null
    }
}

単位の変更に伴う優先手数料の集計の区切り

Legacyおよびv0では、手数料は演算単位あたりのマイクロ・ラムポートで表されます。v1では、ラムポートの絶対総額で表されます。両方を1つのダッシュボードに表示するには、by にアクセスし、v0の価格by を、トランザクションで要求された演算単位の上限に掛け、さらにby を1,000,000で割ります。

20,000 CU × 250,000 マイクロ・ラムポート/CU = 5,000 ラムポート   // v0
                                        5,000 ラムポート   // v1 と同等

換算を省くと、合計値には何の意味もありません。

Geyserstreams にはバージョン制限はありません

ストリーミングサービスの利用者には、これに相当するものがない maxSupportedTransactionVersion しかも、オプトアウトする方法はありません。Yellowstone のGeyserプラグインを15.1.1にアップグレードし、12.6.0以降でProtobufスタブを再生成してください。これにより、 Message.config フィールド。ステールなコンシューマーは v1 に対してエラーを発生させません。このコンシューマーは、トランザクションを v0 として、コンピュート予算が空の状態のままで読み取ります。

構造的にバージョンを検出するには Message.config、そして次の順序で確認してください：

順序が重要なのは、次の理由からです。 バージョン管理済み これは v0 と v1 の両方に当てはまります。これをテストすると、まずすべての v1 トランザクションが v0 として分類され、計算予算はゼロに設定されたまま、何の警告も表示されません。

function messageVersion(message: Message): "legacy" | "v0" | "v1" {
    if (message.config !== undefined) {
        return "v1";
    }
    return message.versioned ? "v0" : "legacy";
}

設定 これはサブメッセージであり、proto3 ではサブメッセージのフィールドには常に明示的な存在が指定されるため、デコーダがデフォルト値をどのように扱うかに関係なく、このチェックは成立します。

古いYellowstone のビルドでは、v1からv0にダウングレードされます

Yellowstone 15.1.1より前のバージョンのgeyserプラグインは、v1トランザクションをネットワークに送信する前にv0形式に変換します。ストリーム自体は引き続き動作しますが、配信されるデータはチェーン上で実行された内容と一致しなくなります。15.1.1以降にアップグレードし、古いビルドの実行中にストリームデータとチェーンの状態を照合していた処理については、この不一致を考慮に入れてください。

v1トランザクションの送信時に何が問題となるか

上記の不具合は、equipe がv1を採用するか否かに関わらず発生します。しかし、以下の不具合は発生しません。以下の変更点は、アプリケーションがv1トランザクションを自ら構築して送信するまでは発生せず、また、すべての項目はトランザクションの読み取り方法ではなく、構築方法の変更に関するものです。レガシートランザクションおよびv0トランザクションは、1,232バイトのまま変更なく動作し続けるため、v1の送信は容量に基づいた判断となります。1,232バイトを超える容量を必要とするトランザクションには、他に選択肢はありません。

設定されていないリソース制限は、デフォルトでゼロになります

レガシー版およびv0では、トランザクションで何も指定されていない場合、1命令あたりの演算ユニット数は200,000、読み込まれる口座データのサイズは64 MiBにフォールバックします。v1では、これらの値はゼロにフォールバックし、トランザクションは失敗します。v1のすべてのトランザクションでは、演算ユニットの制限と読み込まれる口座データのサイズ制限が明示的に設定されます。 @solana/kit 8.0 これらは ComputeBudget の指示からメッセージ設定に移行しました：

import { setTransactionMessageConfig } from '@solana/kit';

const message = setTransactionMessageConfig(
    {
        computeUnitLimit: 20_000,
        loadedAccountsDataSizeLimit: 64 * 1024,
        priorityFeeLamports: 5_000n,
    },
    baseMessage,
);

1回のシミュレーション実行で、両方の制限値をそれぞれ最大値に設定して測定し、返された値を書き出す 消費単位数 そして 読み込まれたアカウントデータのサイズ 設定ファイルに戻ります。データサイズを、次の32 KiBページ単位に切り上げてください。ブロックコストモデルでは32 KiBページ単位で課金されるため、次の境界を下回る分の余裕分は無料となります。

シミュレーションの結果よりも余裕を持たせてください。存在しないアカウントの読み込みにはコストはかかりませんが、一度作成されると64バイトとそのデータ分のコストがかかるため、シミュレーションの結果と厳密に一致するサイズに制限すると、次のエラーが発生します。 MaxLoadedAccountsDataSizeExceeded 取引が反映される前にその口座が表示された場合。

ComputeBudget の命令がノーオペレーションになる

v1ではこれらが受け入れられ、それぞれ150コンピュートユニットが消費されますが、設定に関しては無視されます。ComputeBudget命令を含み、メッセージ設定を含まないトランザクションは検証に合格し、制限なしで実行されます。v1ビルダーからこれらを完全に削除してください。メッセージ設定がこれらに取って代わるため、残された各命令は、利用可能な64の命令スロットのうち1つを消費し、さらに150コンピュートユニットを費やして、何の処理も行わないことになります。

優先手数料

v1 では、優先度手数料は絶対的なラムポート合計として設定されます。v0 での「計算単位あたりのマイクロ・ラムポート」という計算方法は引き継がれません。この値は bigint 型であり、レガシーおよび v0 のメッセージに対してこのセッターを呼び出すと、コンパイル時にエラーとなります：

import { setTransactionMessagePriorityFeeLamports } from '@solana/kit';

const message = setTransactionMessagePriorityFeeLamports(5_000n, baseMessage);

Base58エンコーディングの上限は1,232バイトです

その規模を超える取引には、以下が必要となります。 エンコーディング: "base64" 送信時。base58をハードコーディングした申請は、v1で可能になった大規模なトランザクションでは失敗します。

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendTransaction",
    "params": [
        "<base64-encoded transaction>",
        { "encoding": "base64" }
    ]
}

重複する住所は却下されます

Legacyおよびv0では、1つのトランザクション内でアカウントアドレスが重複しても許容されます。v1では、そのようなケースは拒否されます。

サポート v1に対応しているクライアントのバージョンはどれですか？

v1サポート はここから始まります @solana/kit 8.0.0、4.2.x シリーズの Rust クレート、solders 0.29.0、およびsolana-go 1.23.0。

v1フォーマットは、現在、ローカルバリデータ上で動作しており、機能ゲートは不要です。 solana-テスト・バリデータ バージョン4.2から対応しており、Surfpoolはバージョン1.5から対応しており、さらに SIMD-0296用に構成された一時的なSurfnet ホスティング型のオプションを提供しています。

Quicknode サポート v1用

Quicknode RPCエンドポイントおよびAPIは、アクティベーション時にサポート v1トランザクションを使用します。 エンドポイント 移行、プランの変更、設定フラグ、またはサポート チケットは不要です。

Quicknode Alpenglowクラスターではすでにv1トランザクションが処理されているため、このフォーマットは本番環境の エンドポイント に到達する前に テストネット。 テストネット は、SIMD-0385 トランザクション V1 の有効化を待っており、2026年9月2日（水）10:30（UTC）を予定しています。

残りの作業はアプリケーションコード内で行われます。パス maxSupportedTransactionVersion: 1 on getTransaction そして getBlock、上記のクライアントバージョンにアップグレードし、ComputeBudget命令のスキャンをメッセージ構成に置き換え、フォーマット間で優先手数料単位を統一し、1,232バイトを超えるトランザクションについてはBase64エンコーディングに切り替えてください。