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

Solana がスロット時間を 400ms から 350ms へ ― ジェネシス以来初の短縮で、時間換算に依存する実装が一斉にずれる

Solana がスロット時間を 400ms から 350ms へ ― ジェネシス以来初の短縮で、時間換算に依存する実装が一斉にずれる

何が起きたか

SIMD-0525 は2026年5月14日に承認・マージされ、スロット時間を 400ms から 350ms、300ms、250ms、200ms へと4回に分けて下げる計画を定めている。提案は4段階を一つの変更として扱わず、それぞれ独立した有効化として扱う。

テストネットでは2026年8月5日に第1段が有効化された。メインネットでは、フィーチャーゲートが epoch 1019 の開始スロットである 440,208,000 で有効化され、1エポックの必須遅延を挟んだうえで epoch 1020 の開始とともに 350ms が実効となった。Solana Foundation の技術担当バイスプレジデントである Jacob Creech は8月21日に移行を告知し、次は300msだと述べている。報道時点のメインネット平均スロット時間はおよそ360ミリ秒だった。

この変更は Agave v4.2 に含まれる。Anza は同リリースのメインネット機能有効化を8月17日の週から開始しており、同じリリースには SIMD-0437（レント定数を1バイトあたり 6,960 lamports から 696 lamports へ、およそ90%削減）と SIMD-0296（トランザクション最大サイズを 1,232 バイトから 4,096 バイトへ、新しいトランザクション v1 形式による）も含まれる。新しいコンセンサス Alpenglow のコード一式も v4.2 に入っているが、メインネットでの有効化は行われておらず、2026年10月を目標とする Agave v4.3 で予定されている。

残りの3段階は自動では進まない。各50ミリ秒の削減は、ステーク加重でおよそ3分の2のバリデータが賛同してはじめて有効化され、ブロックのスキップ率が高いままなら次の段へ進まない。

なぜ「速くしてもスループットは増えない」のか

ここが設計の核心である。スロットが短くなれば、1スロットに詰め込める作業は減る。したがって Anza はブロックあたりの計算ユニット上限を比例して引き下げた。従来 100M CU だった上限は、350ms では 87.5M CU になる。毎秒あたりの予算はおよそ 250M CU で一定に保たれ、この値はロードマップの各段階を通じて変わらない。200ms に到達したとき、ブロックあたりの上限は 50M CU になる計算である。

つまり SIMD-0525 は容量の提案ではなく、レイテンシの提案である。確認までの待ち時間が短くなり、リーダーが1回の担当で市場を独占する時間が縮む。リーダースパンは4スロットのまま据え置かれているので、1回のリーダー区間は 1.6 秒から 1.4 秒へ短くなった。検閲耐性の観点では、単一のリーダーが連続して裁量を持つ窓が狭まることに意味がある。

据え置かれたパラメータも重要である。1スロットあたりのティック数は64のまま、リーダースパンは4スロットのまま、1エポックのスロット数は432,000のまま変わっていない。スロット時間だけを動かし、他を触らないという設計判断である。実装の変更点を最小に抑えられる代わりに、スロット数で定義されているすべての量が、実時間では短くなる。

互換性の切れ目：ブロック数で定義された定数の実時間が縮む

エポックが分かりやすい例である。432,000 スロット × 350ms は 151,200 秒、すなわち42時間。400ms では48時間だったので、6時間短くなった。ステーク委任の反映、リワード分配、リーダースケジュールの生成といったエポック境界に紐づく処理は、これまで「およそ2日おき」だったものが「およそ1日18時間おき」になる。cron でエポック境界を近似していたバッチ処理は、数エポックでずれが蓄積する。200ms に到達すれば、エポックは24時間になる計算である。

より刺さるのはトランザクションの有効期限である。Solana では recent blockhash の有効期間がブロック数（150）で定義されており、SIMD-0525 はこの定数を変更していない。したがって実時間の猶予はスロット時間に比例して縮む。単純計算では、400ms のときにおよそ60秒だった猶予が、350ms ではおよそ52.5秒、200ms に到達すればおよそ30秒になる（スキップスロットを無視した計算であり、実際にはこれより長くなりうる。以下同じ）。署名から送信までに人間の確認を挟むフロー、オフラインで署名して後から送るフロー、リトライ間隔を固定秒数で持っているクライアントは、この短縮の分だけ失効しやすくなる。

Agave 側でもこれに合わせた調整が入っている。スナップショット間隔は100スロットから200スロットへ変更された。スロットが短くなった分、同じ実時間をカバーするために必要なスロット数が増えるためである。

同じ Agave v4.2 に含まれる SIMD-0296 も、スロット時間とは独立に互換性に触れる。トランザクションの最大サイズが 1,232 バイトから 4,096 バイトへ広がるが、これは新しいトランザクション v1 形式の導入によって実現される。つまり、上限が緩んだだけでなく、シリアライズ形式そのものが増えた。トランザクションのパース、サイズ検証、署名処理を自前で実装しているクライアントやハードウェアウォレットは、新形式を知らなければ拒否する。上限値だけを設定で持っている実装は、値を書き換えても新形式を扱えるようにはならない。

想定される落とし穴

第一に、段階の進行が「予定」ではなく「投票」で決まる点である。残る3段階はいつ来るか確定していない。300ms への移行が明日かもしれないし、スキップ率次第で数か月止まるかもしれない。したがって「200ms に備える」を一度きりの作業として計画すると、途中の段階ごとに再度ずれが出る。350ms・300ms・250ms・200ms のそれぞれで再計測できるようにしておく必要がある。

第二に、有効化と実効化がずれる。フィーチャーゲートは epoch 1019 の開始スロットで有効化されたが、実際に 350ms になったのは epoch 1020 の開始時である。この1エポックの遅延は運用者にクライアント更新の猶予を与えるために設けられたもので、ゲートが立った時点で挙動が変わったと考えると、観測とログが噛み合わなくなる。

第三に、平均スロット時間は目標値と一致しない。報道時点の実測はおよそ360ミリ秒で、目標の350ミリ秒より長い。スキップスロットとネットワーク条件のためである。実時間換算を目標値だけで行うと、常に楽観側に振れる。SLA や失効判定には実測の分布を使うべきである。

第四に、レント90%削減（SIMD-0437）は5つの独立したフィーチャーゲートに分けて段階的に適用され、必要なら現行値へ戻せるフォールバックゲートも用意されている。つまりレント定数は、この期間に複数回変わりうる。アカウント作成コストを定数として持っている実装は、スロット時間だけでなくこちらでも壊れる。

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

  1. ブロック数で定義された定数を持つプロトコルでは、ブロック生成間隔を変えた瞬間に、その定数の「実時間としての意味」が仕様変更なしに変わる。仕様書のどこにも変更が書かれていないのに挙動が変わるため、差分レビューでは検出できない。これは Solana 固有の話ではなく、ブロック時間を可変にしたチェーンすべてに当てはまる構造である。 ［インテグレーター・ウォレット開発者］ 300ms への移行が提案される前に、コード内でブロック数・スロット数を秒に読み替えている箇所（blockhash 失効判定、リトライ間隔、タイムアウト、エポック境界の cron）をすべて洗い出し、スロット時間を実行時に取得して計算する形へ置き換える。
  2. 段階的フィーチャーゲート方式は、各段でネットワークが立ち止まれる代わりに、外部の実装にとっては「いつ変わるか分からない変更が4回来る」ことを意味する。一度対応すれば終わりという移行モデルが成立しない。 ［プロダクト側・SRE］ 各段階の有効化を検知できるよう、スロット時間とブロックあたり CU 上限を定期取得して閾値アラートを設定し、次のエポック境界までに影響範囲を再評価できる体制を9月中に整える。
  3. スロット短縮はスループットを増やさない。毎秒あたりの計算ユニット予算は一定に保たれており、増えるのは確認の速さと、リーダーの裁量窓の狭さである。性能改善として社内に説明すると、期待値が実測と合わずに信頼を失う。 ［テックリード］ 社内・顧客向けの説明では、350ms 化の効果を「確認レイテンシの短縮」と「リーダー区間 1.6 秒→1.4 秒」に限定して記述し、TPS 向上とは切り離す。

【引用：出典】

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