Solana Transaction v1とは？4,096バイト化の変更点と対応チェックリスト

Solana Transaction v1は、証明や複数署名などで大きくなりやすい取引を扱う新形式です。シリアライズ後の上限を4,096バイトへ広げ、機密送金、複雑なマルチシグ、ゼロ知識証明、プログラム配備などを組み立てやすくします。ただし、容量が増えただけのv0ではなく、生成・署名・取得・保存の各層に形式差が及びます。

本文で使うMTUはネットワークが一度に運ぶデータ量の目安、sanitizeは復号した取引が仕様を満たすか検査する処理、設定マスクはv1メッセージに含めるリソース項目を示す印です。価格に関する予測ではなく、技術移行の判断材料として解説します。

Solana Transaction v1はMainnetで本番稼働済み

Transaction v1は構想段階ではなく、Devnet・Testnetでの段階導入と互換性確認を経て、2026年9月にMainnetで有効化されました。本番有効化はエコシステムの準備を確かめるためEpoch 1035へ延期された経緯があり、ネットワークが受理できることと、利用中のウォレットやデータ基盤が扱えることは分けて考える必要があります。

対応版と検証範囲を分けて確認する

AnzaのFeature Gate Trackerが示すAgaveの最低版は4.2.2です。ただし、これは言語別SDK、CLI、マネージドRPC、Yellowstone gRPCの生成コード、インデクサーまで一律に保証する番号ではありません。各構成要素のリリースノートでv1対応を確認し、本番と同じ依存関係を持つステージング環境で生成、署名、送信、取得、保存まで通してください。

1,232バイトから4,096バイトへ何が変わったのか

v1の分かりやすい変更は、シリアライズされた取引全体の最大サイズが4,096バイトになったことです。ここでいうサイズは、アプリが扱う任意のファイル容量ではなく、ネットワークへ送る取引データの大きさです。署名、アカウント情報、命令、設定などを含むため、利用できる全量をアプリ固有データだけに使えるわけではありません。

従来の1,232バイト上限が抱えていた制約

legacyとv0の1,232バイト上限はIPv6のMTUに由来します。小さな転送には効率的ですが、多数のアカウント、複数の署名、証明データを必要とする処理では、必要な情報を1取引へ収めにくい場合がありました。処理を複数取引へ分けると、途中状態や失敗時の扱いが増え、アプリ側の設計も複雑になります。v0ではALTによりアドレス記載量を圧縮できますが、証明や署名そのもののデータ量を消せるわけではありません。

大容量化で期待される機密送金・マルチシグ・ZK証明・プログラム配備

公式資料では、大容量化の用途として機密送金、複雑なマルチシグ、ゼロ知識証明、プログラム配備などが挙げられています。これらは、通常の単純送金よりも証明や署名、命令データが大きくなりやすい処理です。より大きな書き込みを1取引で扱えることで、プログラム配備の効率改善も期待されています。ただし「常に安くなる」「必ず1取引にできる」とまでは調査資料から言えません。実際の効果は、取引の構成やリソース使用量を測って判断します。

4,096バイトは無制限化ではない

4,096バイトは緩やかな目安ではなく、クラスタが強制する上限です。初期実装では、上限を超えたv1取引を解析時に適切に拒否するための修正や、デシリアライザーとsanitize経路で巨大な取引を受け入れてしまう問題が報告されました。つまり、定数を置くだけでは十分ではありません。生成時、復号時、検証時のすべてで境界を守る必要があります。上限ぴったり、1バイト超過、通常サイズというテストケースを用意すると、経路ごとの差を見つけやすくなります。

legacy・v0・v1の形式差とALT非対応の意味

Solanaでは、legacy、v0、v1の3形式が併存します。v1が登場したからといって、すべての取引が自動で置き換わるわけではありません。取引の目的、必要なアカウント数、接続ウォレットの能力、読み取り基盤の対応を見て形式を選びます。既存のv0取引をそのままv1として再送するのではなく、形式ごとの構造差を理解して再構築する必要があります。

legacy・v0・v1を見分ける基本項目

legacyはバージョン付き取引が導入される前からある形式です。v0はバージョン付き形式でALTを利用でき、取引内にすべてのアドレスを直接書かずに多くのアカウントを参照できます。v1もバージョン付きですが、4,096バイトまで扱える一方、ALTには対応しません。また、リソース設定をメッセージの設定領域に持ちます。解析側は単に「versionedかどうか」だけで分けず、バージョン番号ごとにデコーダーと検証ルールを選ぶ必要があります。

先頭0x81と末尾署名というワイヤ形式

SIMD-0385では、v1はシリアライズ先頭の0x81、10進数では129によって識別されます。さらに、署名が末尾へ配置される点も従来形式との大きな差です。先頭から署名数と署名列が続くという前提で独自パーサーを書いている場合、v1を誤読する可能性があります。データの先頭だけを見て既存形式として処理したり、固定オフセットで署名を抜き出したりしないでください。公式SDKの対応機能を使い、シリアライズ後のバイト列を再度デコードする往復試験が重要です。

最大64アカウントを直接格納する設計

v1では最大64アカウントをメッセージへ直接格納します。ALTという外部の参照表からアドレスを解決しないため、取引単体から関係アカウントを把握しやすくなり、処理の単純化につながります。その代わり、各アドレスを取引内に書くためサイズを消費します。4,096バイトに広がっても、64アカウントの上限と全体サイズの両方を満たさなければなりません。「サイズには余裕があるがアカウント数を超える」「アカウント数内だが証明データでサイズを超える」という別々の失敗があり得ます。

ALT依存処理で必要になるアカウント指定の見直し

既存のv0フローがALTを前提にしている場合、参照テーブルをv1へ添付することはできません。必要なアカウントを直接列挙し、64件と4,096バイトの範囲に収めるよう取引を組み直します。ALTの作成・更新・取得に関する処理を単純に残すと、使われない依存や誤ったサイズ見積もりが残ります。一方、ALTが有効な処理まで無理にv1へ移す必要もありません。v0を維持する経路とv1を選ぶ経路を明確に分けることが実務的です。

v1でリソース上限を明示する方法

v1は取引が大きくなっただけでなく、実行時リソースの指定方法も変わります。設定マスクによって、どの設定値をメッセージに含めるかを示します。この差を見落とすと、見た目は正しくシリアライズできても、実行に必要な値が設定されず失敗する恐れがあります。

設定マスクに含まれる4つのリソース項目

調査資料で示される項目は、優先手数料、Compute Unit（CU）上限、読み込むアカウントデータの上限、ヒープです。優先手数料は処理優先度に関わる指定、CU上限は計算量の枠、読込アカウントデータ上限は実行中に読むデータ量の枠、ヒープはプログラム実行時のメモリ領域に関わります。すべてを常に最大にするという意味ではなく、取引の必要量に応じて設定します。生成ライブラリのデフォルトに依存する場合は、そのデフォルトがどの版でどう定義されるかも確認します。

ComputeBudgetProgram命令との違い

従来形式で使われてきたComputeBudgetProgram命令は、v1のリソース設定には使われません。v1ではメッセージ内の設定マスクと対応する値が基準になります。既存のトランザクションビルダーが計算予算命令を自動挿入する場合、v1用の構築経路でどう処理されるか確認してください。旧命令を残しただけで設定済みと判定するテストは不十分です。デコード後のMessage.config相当の内容と、実際の実行結果を照合します。

設定省略で値が0になるリスク

公式開発リファレンスでは、設定を省略するとCU上限などが0になり、実行不能な取引を作る恐れが示されています。重要なのは、省略が「ネットワークの適切な既定値を自動採用する」とは限らないことです。SDKの型が取引を作れたことだけで成功とみなさず、設定値をログやデコード結果で確かめます。正常系に加え、各フラグを外した場合、0を明示した場合、必要量より小さい場合もテストすると、設定漏れと実行不足を区別できます。

ウォレット対応を送信前に判定する

ネットワークとアプリがv1対応でも、接続中のウォレットがv1へ署名できるとは限りません。未対応ウォレットへv1署名を突然要求すると、エラー表示が分かりにくくなったり、処理が進まなかったりします。送信ボタンを押した後に失敗させるのではなく、取引を構築する前に対応能力を判定する設計が必要です。

supportedTransactionVersionsでv1対応を確認する

Wallet Standardでは、ウォレットが対応する取引バージョンをsupportedTransactionVersionsで表明できます。アプリ側は、その集合に1が含まれるかを確認してからv1を選びます。ウォレット名やユーザーエージェントで推測する方法は、更新や派生版で壊れやすいため避けます。接続直後だけでなく、アカウントやウォレットの切り替え後にも能力を再評価すると、古い判定結果の使い回しを防げます。

未対応ウォレットにはv1署名を要求しない

対応表明がない場合は、「おそらく動く」と仮定してv1を送らないことが重要です。UIでは、現在のウォレットがv1非対応であること、別形式を利用するか処理内容を変更することを具体的に案内します。対応しているはずなのに署名が失敗した場合も、ユーザーへ再試行だけを求めず、生成したバージョン、ウォレットの能力表明、エラー段階を記録できるようにします。秘密情報や署名済み生データを不用意にログへ残さない配慮も必要です。

v0フォールバックを用意する

同じ目的をv0で実現できるなら、未対応ウォレット向けにフォールバックを用意します。ただし、4,096バイトを必要とする処理を1,232バイトのv0へそのまま詰め替えることはできません。ALTを使った再構成、命令の分割、機能制限など、別の組み立てが必要になる場合があります。フォールバックは形式番号だけを変える処理ではなく、要件を満たす別経路として設計し、ユーザーに結果の違いがあれば説明します。

RPC・Yellowstone gRPC・インデクサーの読取対応

v1を送信しないサービスにも対応は必要です。ブロック取得、取引履歴、残高変化の追跡、会計、分析、通知などは、他者が送信したv1取引を読む可能性があります。読み取り側が新形式を拒否すると、特定の取引だけでなく、その取引を含むブロック取得全体が失敗する場合があります。エラーにならず一部フィールドが消えるケースは、さらに発見しにくいため注意が必要です。

maxSupportedTransactionVersionを0に固定する危険

JSON-RPCのリクエストでmaxSupportedTransactionVersionを0に固定すると、v1を含むデータの取得でエラーになり得ます。この設定は、クライアントがどの取引バージョンまで扱えるかをRPCへ伝えるものです。v1対応コードへ更新した後も設定だけが0のままなら、能力と宣言が食い違います。getBlockや取引取得など、実際に利用している各メソッドについて、オプションが共通化されているか、個別に固定されていないかを調べます。

古いgRPC定義がMessage.configを落とす問題

古いYellowstone gRPCの定義から生成されたコードは、v1のMessage.configを認識せず、情報を黙って落とす可能性があります。明確なデコードエラーが出ないまま、優先手数料やCU上限などの解釈に必要な情報が欠ける点が厄介です。.protoファイルだけでなく、そこから生成した各言語のコードと実行環境へ配布された成果物まで更新します。既知のv1取引をJSON-RPCとgRPCの両方で取得し、主要フィールドが一致するか比較すると検出しやすくなります。

保存・索引・手数料集計まで確認する

デコード後のデータベースにも形式差が波及します。取引サイズを1,232バイト前提で制限している列、署名位置を固定した抽出処理、ALT解決後のアカウントだけを保存する設計、ComputeBudgetProgram命令から手数料設定を読む集計は見直し候補です。生データ、正規化テーブル、検索インデックス、キャッシュ、分析ジョブ、管理画面までデータの流れを追ってください。件数が合うだけでなく、設定値とアカウント一覧が欠落していないかを確認します。

SDKと周辺基盤を一式で更新・検証する

v1対応は、依存パッケージを一つ上げる作業ではなく、取引が通る経路全体の更新です。フロントエンドで生成し、ウォレットが署名し、RPCが送信し、ノードが処理し、別のRPCやgRPCが配信し、バックエンドが保存するまでを一本の流れとして確認します。組織内で担当が分かれている場合は、対応版、検証環境、責任者、完了条件を同じ表で管理すると抜けを減らせます。

SDK・CLI・RPC・索引系の対応版をそろえる

互換性表を使い、言語別SDK、CLI、RPC、gRPCクライアント、インデクサーがv1を扱える版かを確認します。ロックファイルに記録された実版、コンテナ内のCLI、コード生成に使った.protoの版も対象です。直接依存だけを更新しても、下位依存に古い取引型が残ることがあります。更新前後で依存関係を保存し、ロールバック時にどの組み合わせへ戻すかも決めておきます。

Rust・TypeScript・Python・Goの公式サンプルで試す

公式サンプル集にはRust、TypeScript、Python、Goでv1の送信・復号・索引を試す材料があります。まずサンプルを変更せずに対象環境で動かし、次に自社のRPCや設定へ置き換え、最後に実アプリの命令へ近づけると、障害の原因を切り分けやすくなります。GoではTransactionV1Configによって形式選択とリソース設定を明示する実装変更も公開されています。各言語で同じバイト列を完全に生成できることより、それぞれが正しく解釈し、ネットワークの制約を守ることを確認します。

JSON-RPCとYellowstone gRPCの両経路を検証する

送信成功だけを完了条件にせず、その取引をJSON-RPCとYellowstone gRPCから取得します。バージョン、署名、アカウント、命令、設定、実行結果を比較し、さらに保存後のレコードとAPI表示まで追います。過去にはv1バイナリの出力に通常のワイヤ形式と異なるシリアライズが使われ、再読込できなくなる実装問題も報告されました。現在使う版で修正済みかをリリース情報で確認し、自分の経路でもserialize、deserialize、sanitizeの往復試験を残してください。

導入前に確認するTransaction v1チェックリスト

読取系を先に整え、生成・署名系を限定的に有効化し、保存・集計と監視・復旧まで同じ既知のv1取引で確認します。担当者は次の各行を消し込み、版、設定値、テスト用取引、実行日時、結果を証跡として残してください。

担当別に残す検証証跡

読取担当は、利用したRPCメソッド、maxSupportedTransactionVersion、返却されたversion、Message.config、署名・アカウント・命令の件数を保存します。gRPC担当は.protoの版だけでなく、生成コードのコミットやパッケージ版、配布済みコンテナの識別子も記録してください。定義ファイルを更新しても、実行環境に古い生成物が残れば、設定値が欠けたままになるためです。JSON-RPCとgRPCから取得した同じ署名の結果を並べ、値が一致することを合格条件にします。

生成・署名担当は、取引を作ったSDKの実版、シリアライズ後のバイト数、アカウント数、命令数、署名数、設定マスクと4つの値、ウォレットが表明した対応バージョンを一組で残します。単に「送信成功」と記録すると、設定省略、ウォレット切替後の能力判定、境界付近だけの不具合を後から切り分けられません。秘密鍵や不要な署名済み生データは共有証跡へ含めず、再現に必要な入力と公開可能な取引識別情報だけを扱います。

保存・集計担当は、RPCまたはgRPCの受信値、生データ列、正規化テーブル、検索インデックス、キャッシュ、外部APIや管理画面の表示を順に照合します。取引サイズを1,232バイトで切る列、先頭側の固定位置から署名を抜く処理、ALT解決済みアカウントだけを前提にした表、ComputeBudgetProgram命令だけから手数料設定を読む集計は重点確認箇所です。件数が一致していても、Message.configが欠ければ完了とは判定しません。

監視・復旧担当は、どのエラー率でv1の新規生成を止めるか、読み取り欠落を検知したときにどのジョブを止めるか、どの期間を再取得するかを決めます。v0への切替はバージョン番号の置換ではなく、必要ならALT、命令分割、機能制限を使う別設計です。v1でしか成立しない処理には、停止時の利用者向け案内も用意します。ロールバック対象には送信機能だけでなく、処理途中のキュー、保存済みの不完全なレコード、再集計ジョブを含めてください。復旧訓練では、意図的にv1取得を失敗させ、アラート、停止、別経路での取得、欠損期間の再処理、集計の再照合までを通します。通常時の成功確認だけでは、障害中に不完全なデータを公開し続ける危険を見つけられません。

境界値は「成功」と「正しい拒否」の両方を記録する

サイズ、署名、アカウント、命令について「上限未満」「上限ちょうど」「上限超過」を分け、クライアント生成、RPC受理、ネットワーク実行のどこで判定されたかを記録します。複数の値が大きい現実的な取引も加え、リソース不足と形式上限を別のエラーとして扱えることを確かめます。境界超過が仕様どおり拒否された結果も合格です。

往復試験は保存・配信経路まで含める

Base64変換、メッセージキュー、異なる言語のサービス、データベースを経由するなら、そこまでを往復試験に含めます。片方が出力したv1をもう片方で読み、0x81、末尾署名、設定マスク、アカウントと命令が失われないことを確認してください。sanitizeは復号後の仕様検査であり、単にパースできたこととは完了条件が異なります。

代替経路と停止条件を本番前に決める

ウォレットが非対応なら、要件を満たすようALTや命令分割を使って組み直したv0経路へ切り替えるか、利用できない理由を表示します。読取失敗時にv1だけを無視すると台帳や集計が不完全になるため、処理を止める条件、対応済み経路からの再取得、復旧後の再処理を決めます。本番では対象を段階的に広げ、v1で得る利点、ALT非対応などの制約、更新・保守費、未確認事項を分けて導入判断を残してください。

まとめ：v1は送信だけでなく読み取りまで対応する

Solana Transaction v1はMainnetで本番稼働し、最大取引サイズを1,232バイトから4,096バイトへ拡張しました。一方で、ALT非対応、最大64アカウント、先頭0x81、末尾署名、設定マスクによるリソース指定など、v0とは異なる設計を持ちます。大きい取引を作れることだけを見て導入すると、ウォレット署名、RPC取得、gRPC配信、保存・集計のどこかで不整合が起こり得ます。

実務では、まず読み取り経路をv1対応にし、対応ウォレットを送信前に判定し、未対応時のv0経路を準備します。そのうえで、4,096バイト、署名12、アカウント64、命令64の境界と、リソース設定、シリアライズの往復を試してください。Solanaそのものの基礎から確認したい場合は、Solanaの仕組みを解説した記事もあわせて読むと、取引形式の位置づけを理解しやすくなります。ゼロ知識証明の背景はゼロ知識証明の基礎解説、プログラムが取引を処理する仕組みはスマートコントラクトの解説で補えます。