Solanaは2026年10月9日、メインネットの目標スロット時間を250ミリ秒から200ミリ秒へ短縮した。これはSIMD-0525の最終段階で、従来の400ミリ秒から半減したことになる。
結論からいえば、JupiterやOrcaなどのDEXは状態更新をより細かく受け取れる一方、処理能力が単純に2倍になる変更ではない。アプリ開発者は、短くなったブロックハッシュ有効時間や固定値による時刻計算を見直す必要がある。
Solanaの200ミリ秒化はすでにメインネットで完了
CoinDeskは当初、Solanaがエポック1053で目標スロット時間を250ミリ秒から200ミリ秒へ短縮する予定だと報じた。その後、Solana Foundationの公式アップグレードページは、2026年10月9日約14時35分（UTC）にエポック1053が始まり、最終段階がメインネットで有効になったと更新している。したがって、現時点では「実施間近」ではなく「実施済み」と捉えるのが正確だ。
スロットとは、指定されたバリデータがブロックを生成できる短い時間枠を指す。目標値が200ミリ秒なら、理論上は1秒に5回のブロック生成機会が訪れる。旧来の400ミリ秒では1秒に2.5回だったため、ウォレット、取引所、Jupiterのようなスワップ集約サービスは、チェーンの新しい状態をより高い頻度で受け取れる。
段階的な移行は、8月21日の350ミリ秒、8月28日の300ミリ秒、9月18日の250ミリ秒を経て、10月9日の200ミリ秒で完了した。各段階を分けたのは、ブロックのスキップ率などを確認しながら運用上の問題を検出するためである。
SIMD-0525で変わったもの、変わらないもの
技術提案SIMD-0525は、単に時計を速めるだけの仕様ではない。スロット当たりの処理上限も時間に比例して縮小し、単位時間当たりの理論的な処理量をおおむね維持する設計になっている。基本表では、最大ブロック計算量は400ミリ秒時の6,000万Compute Unitsから、200ミリ秒時には3,000万Compute Unitsへ下がる。つまり「ブロック数が2倍になったから、総処理能力も自動的に2倍」とは言えない。
一方、1バリデータが連続して担当するリーダースロットは4のまま、1エポックも43万2,000スロットのままだ。4スロット分のリーダー期間は、400ミリ秒設定時の1.6秒から800ミリ秒へ短くなる。特定リーダーが取引を並べ替えたり、選択的に取り込んだりできる連続時間が狭まるため、Solana Foundationは検閲耐性や市場構造の改善につながる変更と説明している。
ただし、目標スロット時間と実測平均は同じではない。Solana Compassは、200ミリ秒段階の開始直後には完了エポックがなく、実測平均をまだ算出できないと明記した。したがって、RaydiumやOrcaの利用者が常に200ミリ秒ごとに確定結果を得られる、と断定するのは適切ではない。ネットワーク伝播、混雑、優先手数料、RPC品質なども実際の待ち時間を左右する。
JupiterやOrcaなどDEXで期待される変化
DEXにとって重要なのは、画面表示の速さだけではなく、価格・残高・流動性プールの状態をどれだけ新鮮な情報で判断できるかだ。たとえばJupiterは複数の流動性ソースを横断してルートを提示するため、ブロックがより頻繁に到着すれば、送信待ちの時間や古い状態を参照する時間を減らせる可能性がある。OrcaやRaydiumのようなAMMでも、スワップ後のプール状態を次のアプリやボットが認識する機会が増える。
また、SIMD-0525はリーダーの連続支配時間を800ミリ秒へ短縮した。これにより、他市場で価格が動いた後も取引を遅らせる、あるいは有利な順序へ並べ替える余地を時間面から狭める効果が期待される。ただし、MEVやサンドイッチ攻撃が消えるわけではない。Jitoを利用するバリデータや取引送信経路、スリッページ設定、優先手数料など、執行品質を決める要素は残る。
ユーザー側では、約定画面の更新が細かくなる可能性はあるが、表示された見積価格と実際の約定価格が一致する保証はない。JupiterやOrcaを使う場合も、価格影響、最低受取額、流動性の深さ、トランザクション失敗時にも発生し得る手数料を確認する必要がある。
ウォレットとDeFiアプリが注意すべき30秒の期限
実務上の大きな変更は、recent blockhashの有効期間が実時間ベースで短くなったことだ。Solanaのトランザクションにはリプレイを防ぐためのrecent blockhashが含まれ、公式ドキュメントでは150スロット有効とされる。このスロット数自体は変わらないが、目標200ミリ秒では約30秒で通過する。400ミリ秒時の約60秒から半分になる計算だ。
PhantomやSolflareなどのウォレットで署名確認に時間がかかる場合、あるいはLedgerなどを使った手動承認、オフライン署名、マルチシグ運用では、署名前にブロックハッシュが古くなる可能性が高まる。DEXのフロントエンドは、トランザクション作成後に長時間待たせないこと、期限切れ時に最新ブロックハッシュで安全に再構築すること、二重送信を避けながら着地確認を行うことが重要になる。
長い承認フローではdurable nonceも選択肢になるが、通常のrecent blockhashとは仕組みが異なる。Squadsのようなマルチシグや法人向けDeFi運用では、単純な再送だけでなく、署名者の待ち時間を含む全体設計を再確認したい。
バリデータ、RPC、インデクサーの負担は増える
ブロック生成機会が増えると、Agaveバリデータは投票やブロック伝播をより短い間隔で処理しなければならない。SIMD-0525はTurbineのデータ配信やReplayの性能改善を前提としているが、ネットワーク接続や処理性能に余裕のない運用者ほど厳しい時間枠に直面する。スロット当たりのデータ量を減らしても、単位時間当たりのブロック数と投票頻度は増えるためだ。
HeliusやTriton OneのようなRPC事業者、Duneや独自分析基盤へデータを送るインデクサーも、データ形式の変更は不要だが、同じ時間内に取り込むブロック数は増える。Solana Foundationは、インデクサーに対してストレージと取り込み能力を計画するよう注意を促している。
さらに、スロット数から経過時間を計算する実装は修正が必要だ。「スロット差×400ミリ秒」という固定式は現在のチェーン状態と合わない。Pyth NetworkやSwitchboardのオラクル更新を参照するDeFiアプリ、清算ボット、利回り集計サービスは、RPCのgetBlockTimeを使うなど、実時間を固定値から推定しない設計が望ましい。
利用者と開発者が確認したい実務チェック
一般利用者は、Jupiter、Orca、Raydiumで取引する際、処理が速く見えてもスリッページ設定を緩めすぎないことが重要だ。混雑時の着地失敗や価格変動は残るため、最低受取額と価格影響を確認し、失敗時に同じ取引を無条件で連打しない。
開発者は、まずrecent blockhash取得から署名、送信までの所要時間を計測する。次に、期限切れエラーを検知して新しいトランザクションを組み直す処理、送信済み署名の確認、RPC切り替え時の重複送信防止をテストする。Jupiter APIを組み込むサービスでも、見積取得からユーザー署名までの待ち時間を含めて検証すべきだ。
バリデータやRPC運用者は、Agaveの対応版、投票処理、帯域、スキップ率、ブロック取り込み遅延を監視する必要がある。200ミリ秒はプロトコル上の目標値であり、各RPCやアプリが同じ遅延を実現するとは限らない。性能評価では平均だけでなく、混雑時の上位遅延や失敗率も見るべきである。
まとめ
Solanaの200ミリ秒スロットは、2026年10月9日にエポック1053で有効となり、SIMD-0525の段階的移行は完了した。ブロック生成機会は400ミリ秒設定時の2倍になるが、スロット当たりの計算量も比例して縮小するため、ネットワーク処理能力がそのまま2倍になる変更ではない。
Jupiter、Orca、RaydiumなどのDEXには、より細かな状態更新と短いリーダー期間による執行環境の改善が期待される。一方で、バリデータの運用窓は厳しくなり、RPC・インデクサーの処理頻度も上がる。ウォレットとDeFiアプリにとっては、recent blockhashの有効時間が目標上約30秒になった点が最優先の確認事項だ。速度向上を評価する際は、目標値だけでなく実測スロット時間、着地率、失敗率、混雑時の挙動を継続して確認したい。
