Cabinet
テクノロジーインサイト一覧へ戻る
2026.08.29

Solana Transaction V1、トランザクション上限を1,232→4,096バイトへ——読み取り側に破壊的変更、送信側は任意

Solana Transaction V1、トランザクション上限を1,232→4,096バイトへ——読み取り側に破壊的変更、送信側は任意

何が起きたか

Solanaのトランザクションは、これまで1,232バイトに収まる必要があった。この値はIPv6の最小MTUである1,280バイトから導かれたもので、ネットワーク層での断片化を避けるための保守的な設計だった。SIMD-0296はこの上限を4,096バイトへ引き上げ、SIMD-0385が上限拡大を運ぶ新しいメッセージ形式「トランザクションv1」を定義する。いずれもAnzaのJacob Creech氏とAndrew Fitzgerald氏によって提案された。

実装はAgave v4.2.2に含まれ、フィーチャーゲートtxv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLLの背後に置かれている。ローカル検証は8月24日からSolana CLI v4.2以降とSurfpool v1.5以降で可能になり、テストネットでは9月1日のエポック1025でゲートが有効化された（Anzaの公式アカウントが同日22:19 UTCに確認）。メインネットの適用日は8月29日にCreech氏がXで9月9日と公表している。ただし本稿執筆時点で確認できた公開情報の範囲では、Solana Foundationのアップグレードページはこの機能を「Pending Feature Activation」と表示したままで、メインネットのゲートが実際に有効化された旨の公式確認は取れていない。運用者は自分のノードでsolana feature statusを実行し、ゲートの状態を直接確認するのが確実である。

上限は1,232バイトから4,096バイトへ、比率にして約3.32倍、絶対量で2,864バイトの増加となる。4,096という値の選択理由として、4KBがバリデータのハードウェアで一般的なメモリページサイズと一致する点が挙げられている。

何のための拡大か、そして何が変わるか

この上限は、単一トランザクションに何を収められるかを直接規定してきた。ゼロ知識証明のペイロードは1,232バイトに収まらないことが多く、多人数のマルチシグやBLS署名の集約、クロスチェーン処理も同様である。開発者は処理を複数トランザクションに分割するか、独自の圧縮を組むかを強いられてきた。分割は原子性を失うため、失敗時のロールバック設計が必要になり、これがアプリケーション側の複雑さの主要因になっていた。4,096バイトは、こうした処理を単一の原子的操作として成立させるための余白である。

一方で、v1はv0の単なる上位互換ではない。報道されている仕様上の差分は次の通りである。バージョンバイトはv0の0x80に対しv1は0x81（10進で129）。署名がトランザクションの先頭ではなく末尾に置かれる。コンピュートバジェットが命令としてではなくヘッダのコンフィグマスクに格納される。そしてアドレスルックアップテーブル（ALT）のサポートがv1では削除されている。ALTはアカウントリストを圧縮するための仕組みであり、これが使えないということは、「多数のアカウントを参照するが総量は小さい」タイプのトランザクションでは、v0のほうが有利なままだという意味になる。v1は大きなペイロードのための形式であって、すべてのケースで置き換わる形式ではない。

レガシー形式とv0は従来どおり動作し、1,232バイトの上限も維持される。つまり送信側にとってv1はオプトインである。しかし読み取り側にとってはそうではない。他人が送ったv1トランザクションは、自分の関与にかかわらずブロックに入ってくる。

上限を上げるとネットワーク層に何が起きるか

1,232バイトという値は、単一のUDPパケットに収まることを担保していた。IPv6の最小MTU 1,280バイトからヘッダ分を差し引いた値であり、経路上のどこでも断片化せずに届くという性質が、Solanaのトランザクション伝播（QUICによる取り込みやTurbineによる配布）の前提を単純にしていた。4,096バイトはこの前提を外す。1トランザクションが複数パケットに分かれるため、欠損や順序の乱れに対する耐性は、上位層の再送・再構成に委ねられる。

設計としては、この複雑さを受け入れる代わりに、アプリケーション側の複雑さ（分割と補償処理）を消す取引をしたことになる。どちらの複雑さを引き受けるかという選択であり、一方的な改善ではない。実務上の含意は、大きなトランザクションほど取り込み段階で落ちる確率が高くなりうるという点で、v1に載せる処理は再送戦略とセットで設計する必要がある。4,096という値が4KBのメモリページサイズに合わせられているのは、この経路上のバッファ確保を単純にするためだと説明されている。

想定される落とし穴

最も刺さるのは、RPCの失敗が「該当トランザクションだけ落ちる」形にならない点である。getBlockは、呼び出しにmaxSupportedTransactionVersion: 1が指定されていない状態でv1トランザクションが1件でもブロックに含まれると、そのブロックの取得全体がエラーになる。他のトランザクションも返ってこない。getTransactionおよびtransactionDetails = fullを指定したgetTransactionsForAddressも同様に失敗する。返るのはJSON-RPCエラーコード-32015である。

このエラーコードは、v1以前から自環境が壊れていたかどうかの検査にも使える。ログに-32015が既に出ているなら、そのプロジェクトはv0（バージョン付きトランザクション）の時点で失敗し続けていたということになる。

もう一つの落とし穴は、パラメータだけ直してSDKを上げないケースである。maxSupportedTransactionVersion: 1を指定してもSDKがv1のレイアウトを解釈できなければ意味がない。公表されている最低バージョンは、@solana/kit が8.0.0（読み取り・送信の両方）、@solana/web3.js 1.x系は1.99.0-beta.0（読み取りのみで、v1の構築・送信は不可）、Rustのsolana-*クレートが4.2.x（読み取り・送信）である。修正の順序は、まずSDKをv1対応版へ上げ、次にパラメータを指定する、である。

生のトランザクションバイト列を自前でデコードしている箇所——独自インデクサ、署名サーバ、リレーヤ——は、SDK更新では救われない。バージョンバイト0x81、末尾に置かれた署名、ヘッダのコンフィグマスクに入ったコンピュートバジェットを扱えないデコーダは、v1を「壊れたデータ」として扱う。失敗が静かに起きる点が厄介で、古いスキーマに対して書かれたクライアントにはv1トランザクションが不完全または不正な形に見える。

最後に、今回の適用は他の変更を連れてこない。SIMD-0437によるレント引き下げ、SIMD-0525によるスロット時間の段階的短縮（8月28日のエポック1024で300msへ）、10月に予定されるAlpenglow（Agave 4.3）は、それぞれ独立した有効化プロセスを持つ。Transaction V1が動いたからといって、他が動いたわけではない。

【技術インサイトとアクション】

  1. この変更は「トランザクションを読む側は送信形式を選べない」という非対称性を可視化した。自社が新形式を使わない判断をしても、他者の使用によって読み取り系が壊れる。同じ非対称性は、あらゆるチェーンのトランザクション形式・イベント形式の拡張で再現する。 ［インテグレーター・データ基盤］ メインネットのゲート状態を今すぐsolana feature statusで確認し、v1トランザクションを含むブロックを取得する統合テストを常設のCIに追加する。
  2. 失敗が「1件のスキップ」ではなく「呼び出し全体のエラー」として現れる設計は、部分的な劣化を許さない。ブロック単位で取得する処理系は、1件の未知フォーマットで全量が止まるという最悪ケースを前提に、再取得とアラートの設計を持つ必要がある。 ［ノード運用者・RPC提供側］ 2週間以内に、-32015をログ監視のアラート条件へ追加し、既存の発生有無を過去ログで確認する。既に出ていれば、v0時点から欠損していた可能性が高い。
  3. v1はv0の上位集合ではない。ALTが使えないため、アカウント参照が多いトランザクションはv0のままが合理的で、形式の選択がアプリケーション設計の判断事項になった。「新しい方に寄せる」という単純な移行方針は、この点で誤りになりうる。 ［コントラクト開発者・SDK利用者］ 次のリリースまでに、自社トランザクションを「ペイロードが大きい」「アカウント参照が多い」で分類し、前者のみv1に載せる方針を明文化する。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。