Solanaはバリデータ間の調整に使う目標スロット時間を250ミリ秒に短縮した。変更は9月18日のEpoch 1037で有効になり、ブロック生成の間隔が短くなった一方、リーダー交代の際にバリデータが取引を受信し、データを転送してブロック生成を始めるまでの時間も縮まった。ネットワークにとって重要なのは平均遅延の低下だけではなく、より限られた時間内でリーダー交代、取引の取り込み、障害復旧を安定して維持できるかどうかだ。
SOLは現在109.89ドルで、24時間では0.90%下落、30日では20.71%上昇している。ただし、スロット時間の短縮そのものがトークン価格のシグナルを意味するわけではない。市場では、ネットワークの可用性や取引確認の体験、バリデータ運用コストに長期的にどのような影響が出るかを見極める必要がある。
Epoch 1037の初期データ、平均スロットは約266ミリ秒
Solanaのエンジニアリング更新によると、目標スロット時間250ミリ秒はEpoch 1037で導入され、切り替え時刻は9月18日05時06分（UTC）ごろだった。9月20日に1分間の観測枠60件を対象として集計した初期サンプルでは、実際に生成されたスロットの平均間隔は約266ミリ秒となった。このEpochで予定されていたスロットのスキップ率は約0.05%だった。
このデータからは、切り替え直後の短期運用でスキップ率が明確に悪化した形跡は確認できない。ただし、観測期間はまだ限られており、長期的なパフォーマンスを示すものではない。より有用な指標となるのは、一定期間にわたるスロット時間、スキップ率、取引の取り込み率、リーダー交代の状況だ。ネットワーク全体の平均値だけでは一部のバリデータやインフラ事業者の弱いパフォーマンスが隠れる可能性があるため、クライアントの種類やインフラ提供会社ごとの分析も必要になる。
Solanaは現在、条件付きでスロット時間をさらに200ミリ秒まで短縮する案も検討している。200ミリ秒化については、9月20日時点でメインネットへの導入日が決まっておらず、Anzaの機能フラグのスケジュールにも明確なリリース日は示されていない。Solanaの説明では、追加の短縮を判断するうえで、ネットワーク性能とスキップ率が重要な条件となる。
スロット短縮でも単位時間の処理容量は増えない
スロット時間の短縮に伴い、SIMD-0525の設計案では1スロット当たりの計算処理上限も引き下げられている。250ミリ秒の場合、1スロットの予算は6250万コンピュートユニットとなる。200ミリ秒に移行すれば、予算は5000万コンピュートユニットに下がる。いずれの設定でも、プロトコル上の名目処理上限は毎秒約2億5000万コンピュートユニットとなる。
つまり、今回の変更がまず変えるのは、取引がブロックに入る頻度と遅延であり、単位時間当たりの計算容量を単純に増やすことではない。ブロックはより頻繁に生成されるが、1ブロックに収容できる処理量は小さくなる。最終的なスループットは、取引需要やスケジューリング、リーダーが利用可能なブロックスペースをどれだけ効率的に埋められるかによって決まる。
リーダーが連続して4スロットを担当するルールは変わらない。250ミリ秒では、各リーダーの名目上の生成時間は約1秒となる。200ミリ秒に短縮された場合、この時間は800ミリ秒に減る。ユーザーにとって取引がブロックに入る機会は増える一方、バリデータはより短い時間でトラフィックの受信、データ伝播、生成担当の切り替えを完了しなければならない。
地理的な距離がリーダー交代の時間を圧迫
Solana Foundationのエンジニアリング分析によると、連続するリーダー間の距離が500キロ未満の場合、最初のスロットは後続スロットに比べ、中央値で約28ミリ秒短くなる。距離が8000キロを超える場合、この差は約122ミリ秒に達する。これは200ミリ秒の目標スロット時間の61%に相当する。
この指標は、リーダーが担当する最初のスロットと後続スロットを比較したもので、単純なネットワーク伝送遅延だけを示すものではない。それでも、スロット短縮に伴う現実的なトレードオフを示している。バリデータを地理的に分散させれば、特定地域への依存を抑えられるが、遠距離にあるリーダー間の交代が生成時間のより大きな割合を消費する可能性がある。
Solanaは9月18日のエンジニアリング更新で、交代時間を確保するための取り組みを2つ挙げた。Agaveの開発者は、取引が当初の送信先に間に合わない可能性がある場合、次のリーダーへ早めに転送する、より保守的な転送方式を検討している。また、複数のクライアントチームが一貫性のあるバイナリを使い、異なる実装やバージョンでブロック実行と取引実行をテストしている。
障害からの復旧にも時間的な制約がある。SIMD-0525の草案では、200ミリ秒段階でも復旧遅延のしきい値を250ミリ秒に維持する。この遅延は目標スロット1つ分を超える。これは設計上の余裕として設定されたもので、現在のネットワークで障害が発生していることを意味しない。ただし、さらなる低遅延化には、より速い復旧、転送、実行の仕組みが必要になることを示している。
TeraSwitchの障害が示したインフラ集中
8月12日に発生したTeraSwitchのルーティング障害は、250ミリ秒への短縮より前の出来事であり、短縮が原因でもない。それでも、複数のバリデータが同じホスティング事業者やネットワーク経路に依存している場合、表面上は独立したノードが同時に影響を受ける可能性を示した。
TeraSwitchの事故記録によると、12拠点がネットワークへの到達性を失い、そのうちマイアミの1拠点は隔離のため切り離された。Solana Compassの試算では、ネットワークのステークの約28.83%が約33分間、接続不能または非アクティブな状態にあった。Solana Foundationは、ブロックの生成は継続し、取引もネットワークに取り込まれていたと説明している。
ネットワークは停止しなかったが、バリデータ数だけでは分散性を十分に把握できないことも明らかになった。9月7日の独立データでは、Solanaのステーク加重によるナカモト係数は18とされ、最大のバリデータはアクティブステークの約4%を占めていた。同じ日のデータでは、TeraSwitchに関連するアクティブステークの割合は22.1%だった。
Solana Foundationは別途、TeraSwitchが「前年」には約38%のステークをホスティングしていたが、その後30%未満まで低下したと説明している。これらの数値は対象日や集計方法が完全には一致していないため、9月7日の22.1%は、過去の数値と連続した時系列を作るよりも、現在時点の独立した観測値として扱う方が適切だ。
ソフトウェアクライアントの構成も、第3の潜在的な障害領域となる。9月20日にステーク加重で集計されたクエリでは、約87.4%のステークが4.xクライアント、7.3%が0.xクライアント、5.3%が26.xクライアントを稼働させていた。大きなバージョン番号は、Agave、Frankendancer、Firedancerのソフトウェア系統を大まかに示すにとどまり、すべてのスケジューラーの派生版や下流ビルドを区別できるものではない。
この3種類のデータは、それぞれ異なる問いに答える。バリデータのステーク集中度は、どの程度のリーダーが機能を失う、または協調して動くと、明確な影響が出るのかを示す。クライアント系統は、バリデータが共通のソフトウェア障害にさらされているかを示す。ホスティング事業者のシェアは、1社のサービスや同一のルーティング領域にどれだけのステークが同時に影響を受け得るかを示す。250ミリ秒化がこれらの集中を生み出したわけではないが、交代や復旧に使える時間が短くなることで、関連する障害の影響が大きくなる可能性はある。
200ミリ秒化には長期運用のデータが必要
現在の250ミリ秒段階では、初期データからスキップ率の急激な悪化は確認されていない。ただし、単一のEpochと約60分のサンプルだけで、200ミリ秒化の導入を判断することはできない。より慎重な評価には、長期間の運用データに加え、ネットワーク負荷、地域分布、クライアント構成、インフラ条件の違いによる結果の比較が必要となる。
Alpenglowは別の技術スケジュールに属する。コンセンサスアップグレードであるAlpenglowは約150ミリ秒のファイナリティーを目標とする一方、スロット時間はブロック生成の機会が訪れる間隔を管理する指標であり、両者は同じものではない。Solanaの公式ページが示す計画時期も完全には一致しておらず、第3四半期を目標とする記述がある一方、Agave 4.3で10月に進める予定を示す記述もある。現時点で正確な有効化日は決まっていない。
今後、市場とバリデータが確認すべきなのは、短期テストにおける平均速度だけではない。取引の転送、リーダー交代、ブロックの修復、異なるクライアント実装が、より小さな時間的余裕の中で継続的に同期できるかが焦点となる。地理的距離、ホスティング事業者、ソフトウェアバージョンによって一部のステークが同時に応答を失った場合でも、200ミリ秒段階で低いスキップ率を維持できるかどうかが、Solanaがスロット時間をさらに短縮する前に検証すべき実務上の課題となる。