Solana(SOL)、トランザクションv1で1件あたりのサイズ上限を4,096バイトに拡大

トランザクションv1、水曜日にメインネットへ

Solana (SOL)は今週水曜日、9月9日にメインネットでトランザクションv1を有効化し、1件のトランザクションが運べるデータ量の上限を1,232バイトから4,096バイトへと3倍以上に引き上げる。今回のアップグレードは2つのプロトコル文書に規定されている。大きいトランザクションを認めるSIMD-0296と、v1フォーマットそのものを定義するSIMD-0385で、いずれもJacob Creech氏とAndrew Fitzgerald氏の執筆によるものだ。従来は2〜3件のトランザクションに分割せざるを得なかった操作が、1回のアトミックな実行で完結できるようになる。

恩恵が最も明確なのは、命令数の多い処理だ。旧上限をしばしば超過していたゼロ知識証明の検証データといった大型暗号学的証明、署名者を1人追加するごとにバイト領域を消費する法人財務やDAO提案のマルチシグ承認フロー、暗号化パッケージを追加で必要とするプライベート送金などが該当する。移行はオプトイン方式で、レガシーのv0トランザクションも引き続き完全に有効だ。ウォレットやアプリケーションは実際に容量が必要になった時点で切り替えればよく、新フォーマットはすでにSolanaのテストネットおよび開発ネットワーク上で安定稼働している。開発者にとっての実利は、長年の回避策からの解放にある。1つの操作を複数トランザクションに分割する運用では、トランザクション間の状態依存の管理や部分的な失敗時のロールバック処理が必要だったが、v1では複雑なロジックが1回のアトミックな実行で完結し、通常のソフトウェア開発に近い形で書けるようになる。戦略的に見ると、この変更はSolana (SOL)がEthereumに対して示してきた唯一の構造的弱点を突くものだ。速度とコストでは長らく優位に立ってきたものの、トランザクションサイズが1,232バイトでハードキャップされていた一方、Ethereumはプロトコルレベルのサイズ制限を設けず、開発者は高いガスを払うだけでデータ密度の高い操作を1件に詰め込める。上限の3倍超引き上げは、この差を大きく縮める。

データ系サービスへの優先手数料の落とし穴

エンジニアリングの負担が重いのは、チェーンに書き込む側ではなく読み取る側のソフトウェアだ。ブロックやトランザクションを取得するすべてのサービス—RPCプロバイダー、データベンダー、エクスプローラーのバックエンド—はv1を認識するようコードを更新しなければならず、対応しないまま新フォーマットに遭遇したリクエストは完全に失敗する。より分かりにくい落とし穴が手数料表示にある。優先手数料は高速処理のためにユーザーが追加する任意のチップだが、v1ではこの情報をv0とは別のフィールドに格納するため、古いソフトウェアは実際に支払われていても手数料ゼロと表示してしまう。Tangemウォレットのようなモバイル系を含むコンシューマー向けウォレット、ブロックエクスプローラー、取引アプリケーションはいずれも画面に表示する内容をこれらのバックエンドサービスに依存しており、解析コードが古いままだとサイレントなデータ誤りがユーザー画面上の誤った数値に直結する。

帯域幅も考慮点だ。ペイロードの大型化はネットワーク容量をより消費するため、大型トランザクションが集中した際にはブロックスペースを巡るユーザーがより高い優先手数料を付けると開発者は見込んでいるが、今回のアップグレードでバイト単位の新課金が導入されるわけではない。そもそも旧上限は名残にすぎない。Solanaの初期ネットワーク設計では、各トランザクションが約1,280バイトのインターネットデータパケットに収まる必要があり、2022年にトランザクション通信の伝送方式が変更されて初めてこの制約は不要になった。新上限がちょうど4,096バイトで止まっているのはハードウェア上の理由による。ブロックチェーンをステーキングベースのバリデーションで支えるマシンでは4キロバイトが標準的なメモリページサイズと一致し、複数ページにまたがるトランザクションはバリデーターの処理コストを大幅に押し上げ、このチェーンの代名詞であるスループットを圧迫するためだ。4,096バイトといっても、複雑なDeFiの構成がこれを日常的に超えるEthereumのL1と比べれば控えめな水準だが、Solana (SOL)自身のエコシステムにとっての狙いは互角化ではなく摩擦の除去にある。市場をリアルタイムで追いたい読者は、Gateで現物および先物の価格をライブで確認できる。

ノード運営者は対応急務

水曜日を前に、アップグレードの技術的詳細のうちいくつかは注意が必要だ。トランザクションv1はAddress Lookup Tablesを廃し、32バイトのアドレスをペイロードに直接埋め込む。ルックアップテーブルに大きく依存するアプリケーションでは、同じアカウント群により多くのバイトを消費するトレードオフになり得るが、Solana自身の分析ではサンプリングされたトランザクションの90%が変換時の増加量を1,400バイト未満に抑えられるとしている。トランザクションあたりの参照アカウント上限は64件のまま変更されないため、ペイロードが大きくなっても自動的に多くのアカウントを操作できるわけではない。v1を送信するアプリケーションは、コンピュートユニットとロードデータの上限を明示的に設定する必要がある。いずれもデフォルトがゼロのためだ。リリースはAnzaのAgave 4.2に同梱されるが、公式ロードマップではメインネットの該当機能はまだ「未アクティブ」、スケジュールも暫定的とされており、9月9日の日程はずれ込む可能性が残る。

有効化を前に、Solanaから1つの釘刺しが出ている。チームは、今回のトランザクション容量拡大が、ネットワーク活動で生じる手数料を通じたSOL発行または焼却の加速スキームを含むSOL供給メカニズムを調整した直近のガバナンス投票とは完全に別物だと強調した。プロトコル側の声明によれば、両変更に直接的なつながりはなく、運営者は水曜日のフォーマット切り替えを供給サイド調整の前触れと読むべきではない。それ以外の有効化スケジュールは予定どおりで、メインネットの機能フラグが立つまでの間、v1フォーマットはテストネットと開発ネットワークで稼働を続ける。

有効化に先立ち、Solana共同創業者のAnatoly Yakovenko氏は拡大された容量の実際の用途を示唆している。同氏は、チェーンには「2つのzkルートを介してデータをアトミックに運ぶ1つのトランザクション」が必要だと述べ、ベースドロールアップがSolana上に存在し得るとの見込みを示した。この捉え方は、単なる余剰容量の先を行く。ゼロ知識証明とロールアップ型の操作を、全てが成功するか何も起きないかのいずれかとなる1回のアトミックなトランザクション内に組み合わせることは、新しいサイズでは一段と実現しやすくなる。別途、Solana Foundationは、マルチシグやConfidential Transfersと並んで、BLS署名とWinternitz一度限り署名を恩恵を受けるワークロードとして挙げている。フォーマットは9月にテストネットで稼働しており、メインネット展開の1か月前のことだ。追加のバイト領域そのものはすでに利用可能になっており、開発者がそれをどれだけ新しいアプリケーション設計に変換するかが、今後の焦点となる。

有効化を前にした追加情報は、このアップグレードがコスト削減につながる可能性を示す。従来複数のトランザクションを要した操作がアトミックに完結できるようになるため、複数ステップのフローを統合する開発者にとって、実行手数料、調整コスト、確定処理の複雑さの削減が見込める。現在の1,232バイト上限は、トランザクションをIPv6ネットワーキングの最小パケットサイズに収めるよう設計されたSolanaの初期アーキテクチャに由来し、QUICプロトコルの採用によってこの制約は実質的に不要となった。Solanaは、レガシーおよびv0トランザクションが既存のルールの下で引き続き動作することも改めて明言しており、大きい上限は開発者が新フォーマットを意図的に採用した場合にのみ適用され、ネットワーク全体に自動展開されるものではない。

(14:39 UTC時点) 大型トランザクション提案をめぐりCOINOTAGの読みでは、今週の負担はインフラ側に集中する。v0のみを解析し続けるRPC運営者、エクスプローラー、ウォレットのバックエンドは、水曜日の有効化後、リクエストの失敗や手数料ゼロ表示に直面しかねない。このタイミングは採用を後押しする材料の重なりとも一致する。SolanaエコシステムはRWA純流入で30日間3億4,800万ドルを記録して首位に立ち、トークン化株式取引で週間30億ドルの過去最高を付けた一方、週次ではETF流入が96%減少と一服している。開発者の回避策をベースレイヤーがまさにこの時期に一掃することは、複雑なロジックを別のチェーンに流す理由をビルダーから1つ減らす。