Solanaは、Transaction v1の導入によって1取引の最大サイズを1,232バイトから4,096バイトへ拡大する計画です。 これにより、DEXの複雑なルーティング、複数署名、暗号学的証明などを、分割せず単一のアトミックな取引へまとめやすくなります。 一方、v1を読み取るRPC、インデクサー、ウォレットなどには更新が必要であり、利用者側でも表示内容の確認が重要です。
Solanaが取引サイズを4,096バイトへ拡大
CoinDeskは2026年9月7日、SolanaがTransaction v1を通じて最大取引サイズを1,232バイトから4,096バイトへ引き上げる予定だと報じました。報道時点ではメインネットでの有効化は9月9日が目標とされていますが、公式開発資料はスケジュールを暫定的なものと位置付けています。実際の利用前には、対象クラスターで機能ゲートが有効になったことを確認する必要があります。
従来の上限は、IPv6の最小MTUである1,280バイトからヘッダー領域を差し引いた設計に由来します。その後、Solanaの取引転送にはQUICが採用され、単一のネットワークパケットへ収めることを前提とした制約を見直せる環境が整いました。
変更内容は、取引サイズを扱うSIMD-0296と、新しい取引形式を定義するSIMD-0385に記載されています。上限が4,096バイトに設定された背景には、バリデーターが利用するメモリページとの整合性があります。無制限に拡張するのではなく、処理効率とアプリケーション側の需要を両立させる設計です。
Transaction v1は何を変えるのか
Transaction v1は、単に既存形式の容量だけを増やしたものではありません。シリアライズ形式が再設計され、先頭のバージョン識別子、命令ヘッダー、設定値、命令データ、末尾の署名という構造を採用します。v1を示すVersionByteは129です。
優先手数料、コンピュートユニット上限、読み込むアカウントデータの上限、ヒープサイズなどは、従来のComputeBudgetProgram命令ではなく、TransactionConfigMaskと対応する設定値に格納されます。この違いを認識しない解析サービスは、実際には優先手数料が支払われていてもゼロと表示する可能性があります。
また、v1ではAddress Lookup Table（ALT）を利用しません。SIMD-0385では、取引あたりのアカウント数は64、署名数は12、命令数は64という従来の上限を維持しつつ、必要なアドレスを取引内へ直接格納します。Jupiterのように多数のプールやプログラムを経由するDEXルーターでは、v0とALTを前提とした構築処理を、そのままv1へ流用できない点に注意が必要です。
DEXの複雑なスワップに期待される効果
DEX分野で注目される用途は、Jupiterに代表される複数市場を横断したスワップルーティングです。取引には、利用者のトークン口座、複数の流動性プール、各DEXのプログラム、手数料設定など、多くのアカウントと命令が含まれます。従来は1,232バイトへ収めるため、経路を短縮する、ALTを準備する、処理を複数取引へ分けるといった対応が必要でした。
容量が4,096バイトへ広がれば、より多くの命令データを単一取引に含められます。Solanaでは取引内の命令が順番に実行され、途中で失敗した場合は取引全体が成立しないアトミック性があります。したがって、承認、スワップ、資産移動などを一つにまとめられれば、複数取引の途中だけが成功するリスクを抑えやすくなります。
ただし、容量の拡大がJupiterなどの約定価格を自動的に改善するわけではありません。価格への影響は、各プールの流動性、スリッページ、優先手数料、ブロック内での競争などにも左右されます。v1は複雑な取引を構築するための技術的余地を広げる変更であり、収益性を保証する機能ではありません。
DeFi、マルチシグ、機密送金への応用
SIMD-0296は、具体的な利用例としてSquadsの企業向けネスト型マルチシグを挙げています。承認者が増えるほど公開鍵と署名の領域が必要になるため、従来のサイズ上限は複雑な承認フローの制約になっていました。v1によって、より情報量の多い承認操作を単一取引へ収めやすくなります。
暗号学的な用途では、SolanaのConfidential Balancesで利用されるゼロ知識証明や、BLS、Winternitzワンタイム署名なども例示されています。こうした証明データは一般的なトークン送金より大きく、1,232バイトでは分割や別の仕組みが必要になる場合があります。
Jito Bundlesも関連事例です。開発者は複数取引をまとめることで、従来のサイズ制約を実務上補ってきました。しかしSIMD-0296は、バンドルとプロトコル上の単一取引では保証が同一ではないと説明しています。4,096バイトに収まる処理であれば、単一のv1取引へ移行することで、Solana本来のアトミック性を利用できる可能性があります。
RPC・ウォレット・分析サービスには更新が必要
既存のlegacy取引とv0取引は引き続き利用でき、追加容量を必要としないPhantomやSolflareなどのウォレットが、送信処理を直ちにv1へ切り替える必要はありません。一方、v1の送信が任意であっても、チェーン上の全取引を読むサービスにとって対応は任意ではありません。
RPCノード、Yellowstone gRPCを利用するインデクサー、Solscanのようなエクスプローラー、DEXの取引履歴画面は、新しい形式を正しくデコードする必要があります。未対応のサービスでは、ブロック取得が失敗する、v1取引だけ履歴から欠落する、優先手数料が誤表示されるといった問題が起こり得ます。
とりわけ注意したいのは、画面上では通常どおり動いているように見える「静かな障害」です。たとえば取引自体は成功していても、分析基盤が新しい設定領域を読まなければ、費用集計やDEXの収益分析が不正確になります。DeFi事業者は、送信SDKだけでなく、データ取得、会計、監視、顧客サポートまで含めて確認すべきです。
開発者と利用者が確認すべきポイント
Jupiter、Squads、独自DeFiアプリなどの開発者は、まずSolana公式資料に記載されたenable_tx_v1機能ゲートを確認し、対象クラスターで有効になる前にv1取引を送信しないことが基本です。devnetやtestnetで動作していても、mainnet-betaで同じ状態とは限りません。
次に、v0でALTを利用している処理とv1の処理を分離し、取引サイズ、利用アカウント、署名数、命令数を送信前に検証します。RPCやgRPCについては、既知のv1取引を使って、ブロック取得、取引デコード、優先手数料表示、失敗取引の解析までテストする必要があります。
利用者は、PhantomやSolflareなどのウォレット、利用するDEX、エクスプローラーがv1へ対応しているかを公式案内で確認しましょう。同じ取引を複数の画面で見比べ、手数料やステータスが食い違う場合は、表示だけを根拠に再送信しないことが重要です。大きな取引はネットワーク帯域を多く使うため、混雑時には高い優先手数料が必要になる可能性もあります。ただし、今回の提案に新しいバイト単位の手数料は含まれていません。
まとめ
SolanaのTransaction v1は、最大取引サイズを1,232バイトから4,096バイトへ拡大し、Jupiterの複雑なルーティング、Squadsのマルチシグ、Confidential Balancesの証明などを単一取引へまとめやすくするアップグレードです。
その価値は、単なる容量増加だけではありません。コンピュート予算と優先手数料の格納方法を見直し、バリデーターが取引を効率的に取り込める形式を目指しています。その反面、ALTを利用できないことや、RPC・インデクサー・ウォレット側の対応が必要になることは重要な移行課題です。
開発者は機能ゲートと公式SDKの対応状況を確認し、送信と読み取りの両方をテストする必要があります。利用者にとっても、手数料や取引履歴の表示が正しいかを確かめることが、安全にDEXやDeFiを利用するうえで欠かせません。
