Solanaは2026年8月、メインネットの目標スロット時間を400ミリ秒から350ミリ秒へ短縮しました。これは取引確認の待ち時間を減らし、最終的に200ミリ秒を目指す段階的アップグレードの第1弾です。
ただし、今回の変更はネットワーク全体の処理能力を直接増やすものではありません。1スロット当たりの処理上限も比例して調整し、単位時間当たりの負荷をほぼ維持しながら低遅延化する設計です。
Solanaメインネットで何が変わったのか
The Blockによると、Solanaは2026年8月21日、メインネットの目標スロット時間を従来の400ミリ秒から350ミリ秒へ短縮しました。スロットとは、指定されたバリデータがトランザクションをまとめ、ブロックを生成できる短い時間枠です。
今回の変更は、Solana Improvement Document「SIMD-0525」に基づきます。同提案では、目標スロット時間を350ミリ秒、300ミリ秒、250ミリ秒、200ミリ秒の4段階で短縮する方針が定められています。各段階は個別のフィーチャーゲートで有効化され、問題が発生した場合は次の段階へ進む前に停止できます。
Solana Foundationの公式アップグレード資料によれば、この段階方式はブロックスキップ率などを監視しながら安全性を検証するためのものです。DevnetとTestnetではメインネットに先行して短縮設定が導入され、AgaveやFiredancerなど複数のバリデータクライアントを含む環境で検証が進められました。
350ms化で取引確認はどう速くなるのか
Solanaのコンセンサスでは、取引の確認状態がスロットの進行と密接に関係しています。同じスロット数を待つ処理であれば、1スロットが短くなるほど、実時間で見た確認待ちも短くなります。
例えば、ウォレットからJupiterでスワップを送信した場合、トランザクションの取り込み、後続スロットの生成、RPCによる状態更新が従来より短い間隔で進む可能性があります。Raydiumで流動性を追加する操作や、Orcaでポジションを変更する操作でも、画面上の状態が更新されるまでの体感時間が改善する余地があります。
ただし、350ミリ秒は「すべての取引が350ミリ秒で確定する」という意味ではありません。ユーザーが感じる待ち時間は、RPCの応答速度、トランザクションの優先手数料、リーダーへの到達経路、ブロックへの収容状況、アプリ側の確認レベルなどにも左右されます。
The Blockが変更前後に行った時点調査では、変更前の1,000スロットが415秒、変更後の同規模区間が368秒だったと報告されています。これは目標値に近づいたことを示す観測例ですが、ネットワークの恒常的な性能を保証するベンチマークではありません。
なぜスループットは自動的に増えないのか
スロットが短くなればブロック生成回数は増えますが、それだけで1秒当たりの総処理量が増えるわけではありません。SIMD-0525は、スロット時間の短縮率に合わせて、1スロット当たりの計算量やデータ量などの上限も縮小する設計を採用しています。
今回の350ミリ秒段階では、400ミリ秒を基準とした各種上限を原則として350対400の比率で調整します。つまり、バリデータは短い間隔で次のスロットを処理する一方、各スロットに詰め込む仕事量も減ります。狙いは、単位時間当たりの負荷を急増させずに確認間隔を短くすることです。
これは、Jupiterのアグリゲーション、RaydiumのAMM、Driftのデリバティブ取引などで利用者が増えた際に、単純に取引収容能力が拡大する変更ではないことを意味します。混雑時の約定しやすさには、別途ブロックのCompute Unit上限、優先手数料市場、トランザクション伝播、アプリ側の送信設計などが影響します。
Solanaでは2026年7月にSIMD-0286がメインネットで有効化され、ブロック上限を引き上げる別の改善も実施されました。スロット時間の短縮とブロック計算上限の拡大は関連しますが、目的と仕組みが異なるアップグレードとして区別する必要があります。
DEXとDeFi利用者に期待される効果
最も分かりやすい利点は、価格変動が速い場面でオンチェーン状態をより細かく更新できることです。Jupiterで複数の流動性ソースを比較してスワップする場合や、Driftで担保状況を確認する場合、スロット間隔が短くなれば、アプリが新しいブロック状態を観測できる機会も増えます。
Pyth Networkなどのオラクル価格を参照するDeFiプロトコルにとっても、時間をスロット単位で評価する処理の粒度が細かくなります。SIMD-0525は、オラクル利用者やプロアクティブ型AMMのようにデータの鮮度を重視するアプリケーションを、短いスロットの恩恵を受ける例として挙げています。
また、バリデータが連続して担当するリーダー区間は4スロットのまま維持されます。そのため、1回のリーダー担当時間は400ミリ秒時代の1.6秒から、350ミリ秒段階では1.4秒へ短縮されます。特定のリーダーがトランザクションを遅延、並べ替え、選択的に収容できる時間が短くなるため、市場構造や検閲耐性の面でも改善が期待されています。
一方、利用者が取るべき操作は基本的に変わりません。スワップ前には価格への影響、許容スリッページ、優先手数料、トークンの真正性を確認し、失敗した取引を反射的に連続送信しないことが重要です。低遅延化は価格変動やMEV、スマートコントラクト固有のリスクを解消するものではありません。
開発者とバリデータが確認すべき点
DeFi開発者は、時間を固定の400ミリ秒として計算しているコードがないか確認する必要があります。Solana Foundationは今回の変更を破壊的変更として扱い、インデクサー対応の要否を未確定としています。スロット数を秒へ変換するSDK定数、取引期限、キャッシュ更新、監視アラートなどは特に注意が必要です。
ブロックハッシュの有効期限やタイムアウトを単純な秒数で推定するウォレット、ボット、Keeperも再検証が必要です。Jupiter APIを利用するスワップUI、Driftの自動処理、Pyth価格を監視する清算・裁定システムでは、固定時間ではなくRPCから得た実際のスロットやブロック状態を基準にする方が安全です。
バリデータ側では、Agave、Jito-Agave、Firedancerなど利用クライアントの対応版と運用要件を確認する必要があります。スロット短縮によりブロック生成、Turbineによる伝播、Replay処理を完了する時間的余裕が小さくなるため、ハードウェア性能やネットワーク接続が不十分な環境ではブロックスキップ率が上昇する可能性があります。
SIMD-0525では、各フィーチャーゲートが有効化された直後ではなく、1エポックの遅延を経て新しい設定を適用します。スナップショット、インフレーション計算、shred検証などが移行境界を正しく扱えるようにするためです。
200msへのロードマップとAlpenglowとの違い
350ミリ秒は最終地点ではありません。計画上は300ミリ秒、250ミリ秒、200ミリ秒へ段階的に短縮されます。ただし、次のメインネット段階となる300ミリ秒への移行日は、The Blockの報道時点で設定されていません。開発者は350ミリ秒環境の安定性を監視してから判断する方針です。
スロット時間の200ミリ秒化と、Solanaが開発を進める新コンセンサス「Alpenglow」は別の取り組みです。前者はブロック生成の時間枠を短くする変更であり、後者はコンセンサスとファイナリティの仕組みを大きく見直す計画です。「200ミリ秒スロット」と「短時間の最終確定」を同じ意味として扱うべきではありません。
また、スロット数が固定されたまま時間だけ短くなるため、432,000スロットで構成されるエポックの実時間も短縮されます。SIMD-0525の設計値では、400ミリ秒段階の約48時間から、350ミリ秒段階では約42時間になります。200ミリ秒に到達した場合は約24時間です。インフレーションが実時間ベースで意図せず変化しないよう、年間スロット数の換算値も段階ごとに調整されます。
まとめ
Solanaの350ミリ秒化は、処理能力を無理に引き上げるのではなく、単位時間当たりの負荷をおおむね維持しながら取引確認を高速化するアップグレードです。Jupiter、Raydium、Orca、DriftのようなDEX・DeFiサービスでは、状態更新の粒度や操作後の応答性が改善する可能性があります。
一方で、混雑時の取引成功率やスループットが自動的に向上する変更ではなく、最終確定時間とも区別が必要です。利用者は従来どおりスリッページや優先手数料を確認し、開発者は400ミリ秒を前提とする実装を点検するべきでしょう。
今後は350ミリ秒環境でのブロックスキップ率、バリデータクライアントの安定性、RPCやインデクサーの対応状況が焦点になります。300ミリ秒以降への移行は既定路線ではあるものの、実際の有効化時期はネットワーク上の検証結果を踏まえて決まります。
