Solanaは2026年9月9日（水）、メインネット上でTransaction v1機能を正式に稼働させ、最大トランザクション容量を1,232バイトから4,096バイトへと3倍以上に拡大する。このアップグレードは、2つのSolana改善提案、SIMD-0296（より大きなトランザクション）とSIMD-0385（Transaction v1フォーマット）によって定義されている。
Transaction v1の技術仕様
Transaction v1は、2つのSolana改善提案によって共同で定義されている。SIMD-0296はトランザクション上限の拡大を規定し、SIMD-0385はTransaction v1のフォーマットを定義している。両提案はJacob CreechとAndrew Fitzgeraldが共同で執筆した。新機能はテストネットと開発ネットでしばらく安定稼働しており、2026年9月9日にメインネットで正式に稼働を開始する。
Transaction v1は後方互換性を考慮して設計されており、既存のv0フォーマットも引き続き有効である。ウォレットやアプリケーションは、より大きなトランザクション容量が必要な場合にのみv1フォーマットを採用すればよく、強制的な移行は求められない。
Transaction v1が最も直接的な恩恵をもたらす3種類のトランザクションシナリオ
容量が1,232バイトから4,096バイトへ拡大したことで、以下の3種類のトランザクションが最も直接的な恩恵を受ける。
大規模な暗号学的証明：ZK proofなどの検証データは、これまで1,232バイトの制限を超えることが多く、複数のトランザクションに分割せざるを得なかった。Transaction v1では、完全なZK検証データを単一のトランザクションにまとめて送信できる。
マルチシグ承認プロセス：企業の金庫やDAOの提案など、複数の署名者による承認が必要な資金移転では、各署名が容量を消費する。v1により、マルチシグ承認プロセスを単一のトランザクション内で完了できる。
機密送金：一部のプライバシー取引メカニズムでは追加の暗号化処理が必要となるため、従来の容量ではトランザクションが失敗したり、効率が低下したりしていた。4,096バイトへの拡大により、この種の操作に十分な容量が確保される。
4,096バイト上限が設定された理由
上限を4,096バイト（4KB）に設定した背景には、ハードウェア上の考慮がある。これはバリデーターノードが使用する標準的なメモリーページのサイズであり、1件のトランザクションが複数のメモリーページにまたがると処理コストが大幅に上昇し、Solanaの高TPS（1秒あたりのトランザクション数）の維持に不利となる。そのため、4KBは容量の拡大とネットワーク性能の維持との間のバランスポイントとなる。
従来の1,232バイト制限は、Solana初期のネットワーク設計に由来する。各トランザクションを約1,280バイトのIPパケット内に収める必要があったためである。2022年、Solanaはトランザクションデータの伝送方式を調整し、この厳格な上限は必要なくなった。Transaction v1の導入は、この歴史的な設計上の制限を正式に撤廃するものである。
RPCノードと読み取りサービスに必要な更新
Transaction v1は、トランザクションの書き込みよりも、オンチェーンデータの読み取りサービスに大きな影響を与える。ブロックやトランザクションデータを取得するすべてのサービス（RPCノード、オンチェーンデータプロバイダー、ウォレットのバックエンド）はコードを更新する必要があり、更新しなければv1フォーマットのトランザクションに遭遇した際にエラーを返す。
もう1つの具体的な影響は、優先手数料（priority fee）のフィールド位置にある。v1では優先手数料の情報がv0とは異なるフィールドに保存されるため、旧バージョンのソフトウェアでv1トランザクションを読み取ると、ユーザーが実際には優先手数料を支払っていても「手数料ゼロ」と表示される。ウォレットのインターフェース、ブロックチェーンエクスプローラー、取引アプリが更新されていない場合、ユーザーには不正確な手数料が表示されることになる。
Ethereumとの容量比較
プロトコル設計の観点で比較すると、Ethereumにはプロトコル層でのトランザクションサイズ制限がない。開発者はより高いGas代を支払うことで、データ集約型の操作を単一のトランザクション内で実行できる。一方、Solanaにはこれまで、「1件のトランザクションにどれだけの命令を収容できるか」という点で明確な制限があった。Transaction v1によって上限が4,096バイトに引き上げられたことで、両チェーンの差は縮まったが、Ethereum L1にとって4,096バイトは依然として大きなサイズではない。Ethereum上の複雑なDeFiコンポジットトランザクション（複数プール間のアービトラージや複数資産の貸し借りなど）は、この数値を超えることが多い。
Solanaエコシステムにとって実際に技術的な意味があるのは、開発者が回避策を講じる必要がなくなる点である。これまでは操作を複数のトランザクションに分割する際、トランザクション間の状態依存や失敗時のロールバックを処理する必要があった。Transaction v1により、複雑なロジックを1つのアトミックな操作で完了できるようになり、従来のプログラミングモデルにより近づく。
よくある質問
Solana Transaction v1の稼働開始日、最大容量の変更、定義提案は？
Solana Transaction v1は2026年9月9日（水）にメインネットで稼働を開始し、最大トランザクション容量は1,232バイトから4,096バイト（3倍以上）に拡大する。このアップグレードはSIMD-0296とSIMD-0385の2つの提案によって定義され、Jacob CreechとAndrew Fitzgeraldが共同で執筆した。これに先立ち、テストネットと開発ネットで安定稼働していた。
4,096バイトの上限は、なぜより大きな数値ではなくこの数値に設定されたのか？
4,096バイトはバリデーターノードが使用する標準的なメモリーページのサイズであり、1件のトランザクションが複数のメモリーページにまたがると処理コストが大幅に上昇し、Solanaの高TPSの維持に不利となる。4KBは、容量の拡大とネットワーク性能の維持との間のバランスポイントである。
RPCノードと読み取りサービスはどのように更新する必要があり、優先手数料フィールドの変更による具体的な影響は？
ブロックやトランザクションデータを取得するすべてのサービスはコードを更新する必要があり、更新しなければv1トランザクションに遭遇した際にエラーを返す。v1の優先手数料フィールドの位置はv0と異なるため、旧バージョンのソフトウェアで読み取ると、ユーザーが優先手数料を支払っていても「手数料ゼロ」と表示される。ウォレットやブロックチェーンエクスプローラーが更新されていない場合、正確でない手数料情報が表示される。
