SolanaのTransaction V1は、1取引のサイズ上限を1,232バイトから4,096バイトへ拡大する新形式です。 これにより、DEXの複数ステップ取引、企業向けマルチシグ、ゼロ知識証明などを、分割せずアトミックに実行できる余地が広がりました。 ただし、処理速度やTPSが単純に3倍になる更新ではなく、ウォレットやRPC、データ基盤にはV1対応が必要です。
SolanaでTransaction V1がメインネット稼働
Solana Foundationは2026年9月15日、メインネットのepoch 1035でTransaction V1を有効化しました。最大トランザクションサイズは従来の1,232バイトから4,096バイトへ拡大され、利用可能なデータ量は約3.3倍になりました。
トランザクションには、署名、参照するアカウント、命令、プログラムへ渡すデータなどが含まれます。従来はこれらを合計して1,232バイト以内に収める必要があり、複雑な処理では容量が先に不足することがありました。
例えばJupiterのようなDEXアグリゲーターでは、複数の流動性プールを経由するスワップ経路や、スワップ前後のトークン口座処理など、多数の命令とアカウントを扱います。V1によって必ずルートが改善するわけではありませんが、容量不足を理由に処理を分割・簡略化していた設計には新しい選択肢が生まれます。
なお、legacy形式とV0形式も引き続き利用できます。すべての利用者やアプリが直ちにV1へ移行しなければならないハードフォーク型の変更ではありません。
1,232バイト制限がDEX開発を難しくしていた理由
Solanaの取引は、複数の命令を一つにまとめ、全体を成功または失敗として処理できます。この「アトミック性」はDEXにとって重要です。例えばOrcaでトークンを交換し、その結果を別のDeFiプロトコルへ預ける場合、途中だけ成功するとユーザーが意図しない資産状態になる可能性があります。
ところが従来の1,232バイト制限では、必要な署名、アカウント、命令データが収まらず、処理を複数取引へ分割しなければならない場合がありました。分割すると、最初の取引だけ成立して後続が失敗するリスクや、複数回の署名・確認をユーザーへ求める負担が生じます。
V0ではAddress Lookup Tables（ALT）を利用し、アカウントアドレスを圧縮して参照する方法が提供されていました。一方、V1ではALTが廃止され、使用するアカウントをメッセージ内へ直接記載します。それでも4,096バイトの容量があるため、公式資料では最大64アカウントをインラインで扱える設計と説明されています。
つまりV1の価値は、単にデータを多く詰め込めることだけではありません。ALTの作成・維持・解決に依存せず、JupiterやOrcaを組み込むクライアントが、より自己完結した取引を構築できる点にもあります。
複雑なDEX取引とマルチシグへの効果
Transaction V1の恩恵が期待される代表例は、複数ステップのDEX取引です。Jupiterのようなルーティングサービスでは、単一プールで交換するより、複数の市場を組み合わせた方が有利な結果を提示できる場合があります。しかし、経由先が増えれば命令や参照アカウントも増え、取引サイズの制約を受けやすくなります。
容量拡大により、トークン交換、口座作成、担保操作などを一つの取引へまとめられる余地が増えます。複数取引をJito Bundleなどで連携させていた一部の処理も、内容によっては単一のアトミック取引として設計できる可能性があります。ただし、4,096バイト以内であっても、コンピュートユニットやアカウント数など別の上限は残ります。
企業・DAO向けでは、Squadsのようなマルチシグ基盤が具体例です。承認者が多い取引では署名情報の占める容量が増えます。V1は大型マルチシグやオンチェーン署名方式を主な用途として挙げており、複数承認を伴う財務管理やプロトコル運営で、取引分割を減らせる余地があります。
ただし「容量が増えたためDEXの価格が必ず改善する」「手数料が必ず安くなる」とは限りません。実際の効果は、各プロトコルがV1を採用するか、ルーターがどのような取引を生成するかによって異なります。
ゼロ知識証明とプライバシー用途にも追い風
ゼロ知識証明は、元の情報を公開せず、ある条件が正しいことを検証する技術です。証明データや検証用パラメータは容量を必要とするため、小さなトランザクション上限が実装上の障壁になることがあります。
Solana Foundationは、V1によって拡張される用途としてZK proofsを明示しています。Light Protocolなど、Solana上でゼロ知識技術や圧縮状態を利用するプロジェクトにとって、単一取引へ格納できる証明・署名・命令データが増えることは、設計の自由度を高める要素です。
もっとも、サイズ上限の拡大だけで証明生成が高速化したり、計算コストが消えたりするわけではありません。Solanaでは取引ごとのコンピュートユニット上限が別に存在します。大きな証明を格納できても、その検証処理が実行予算内に収まるかは別途確認が必要です。
DEX分野では、取引内容や残高情報の秘匿、条件付き決済、コンプライアンス要件を満たした証明などへの応用が考えられます。ただし、JupiterやOrcaなど既存DEXが直ちにプライバシー取引へ移行するという意味ではなく、V1はその基盤となり得る容量を提供する更新と捉えるべきです。
Ethereumとの差はどこまで縮まったのか
CoinDeskは今回の更新を、SolanaがEthereumとの差を縮める動きとして報じました。従来のSolanaには1,232バイトという固定上限があり、データ量の多いアプリケーションではEthereumの方が柔軟に処理を組み立てやすい場面がありました。
EthereumはSolanaの旧形式のような一律の1,232バイト上限ではなく、計算やデータ利用をガスとして課金します。UniswapのスワップやAaveの資産操作のように複雑な取引では必要ガスが増え、利用者が設定した取引ガス上限と、ブロック全体のガス上限の範囲内で処理されます。
この違いから、Ethereumは高コストを受け入れればデータ量の多い取引を構成しやすい一方、Solana V1は4,096バイトという明確な上限を維持します。そのため、V1によって実用上の差は縮まっても、両ネットワークのリソース管理方式が同じになったわけではありません。
また、Solana V1でも最大アカウント数やコンピュートユニットなどの制約は残ります。Ethereumに対する優位性を判断する際は、取引サイズだけでなく、ガス・手数料、実行失敗率、流動性、MEV対策、ウォレット対応まで比較する必要があります。
ウォレット・RPC・データ事業者に必要な対応
一般利用者は、Phantomなど利用中のウォレットやJupiterなどのアプリがV1へ対応すれば、新形式を意識せず利用するケースが中心になるでしょう。一方、開発者とインフラ事業者には具体的な更新が必要です。
SolanaのRPCでV1取引を取得する場合、リクエスト側でmaxSupportedTransactionVersion: 1を指定する必要があります。V1メッセージにはtransactionConfigが追加され、コンピュートユニット上限、ヒープサイズ、読み込みアカウントデータ上限、優先手数料などのリソース設定が格納されます。
ブロックエクスプローラー、会計ツール、DEX分析サービス、インデクサーがV1を解釈できなければ、取引の表示欠落やデコードエラーが起こり得ます。HeliusのようなRPC事業者、ウォレット、Jupiterを監視するデータサービスは、シリアライズ、署名検証、取引取得、履歴表示まで一連のテストが必要です。
またV1ではALTを利用できず、リソース上限の指定方法も従来形式と異なります。単純に旧取引のバージョン番号だけを変更するのではなく、公式SDKとドキュメントに沿ってメッセージ構築処理を更新することが重要です。
まとめ
Transaction V1は、Solanaの最大トランザクションサイズを1,232バイトから4,096バイトへ拡大した重要な基盤更新です。Jupiterの複雑なルーティング、Squads型マルチシグ、Light Protocolに代表されるゼロ知識技術など、データ量の多い処理を単一取引へまとめられる可能性が高まりました。
一方、今回増えたのは1取引に格納できるデータ量であり、TPSや実行性能がそのまま3.3倍になったわけではありません。コンピュートユニット、アカウント数、流動性、アプリ側の実装といった制約も残ります。
利用者は対応ウォレットやDEXの更新状況を確認し、開発者はRPCの対応バージョン、V1のリソース設定、ALTを使わない取引構築を検証する必要があります。SolanaとEthereumの差は一部縮まりましたが、最終的な使いやすさは各DEXやインフラがV1をどう活用するかで決まります。
