Solanaの「地理対応リーダースケジュール（Geo-Aware Leader Schedule）」は、ブロック生成を担当するバリデータの割当数を変えず、並ぶ順序を地理情報で組み替える提案です。近い場所のリーダーを続け、交代時の通信遅延を減らす狙いがあります。目標スロットが400msから200msへ短くなる局面では、仮に交代が60msなら占有率は15%から30%へ倍増するため、数十msの差が相対的に重くなります。
ただし、2026年10月16日時点のSIMD-0674とSIMD-0675は提案段階です。本番ネットワークで有効化された機能ではありません。また、平均29.1msの短縮は特定条件のシミュレーション結果であり、すべての取引が29.1ms速くなるという意味でもありません。
この記事では、従来方式との違い、二つのパラメータ、試算の読み方、地域障害や位置偽装のリスク、今後の確認方法を順番に解説します。読み終えると、「速くなるらしい」という見出しだけでなく、何を維持し、何を変え、どんな交換条件を負う提案なのかを判断できます。とくに性能の平均値だけでなく、短時間の地域集中が障害耐性や検閲耐性へ与える影響まで同じ表で比べることが、本稿の目的です。
Solanaの地理対応リーダースケジュールとは
Solanaの基本的な仕組みでは、時間を細かな「スロット」に区切り、それぞれのスロットで台帳へデータを書き込むリーダーを決めます。地理対応リーダースケジュールは、その担当者の列を地理的な近さに応じて再配置し、前のリーダーから次のリーダーへ役割が移る際の待ち時間を小さくしようとする設計です。
大切なのは、ステークを多く持つバリデータほど多く選ばれやすいという土台を捨てる提案ではない点です。まず従来のステーク加重方式で割当を作り、その結果に含まれる担当回数を保ったまま順番を動かします。したがって、「地域を基準に新しく当選者を選び直す仕組み」と理解すると不正確です。
SIMD-0674とSIMD-0675の関係
提案は二つに分かれています。SIMD-0674は、バリデータが位置コードと座標を登録・更新するための前提を定めます。SIMD-0675は、登録された位置を使って、既存のリーダー割当を地理的に並べ替える本体です。
0674が「どこにいると申告するか」を扱い、0675が「その情報を順序へどう反映するか」を扱う、と分けると理解しやすいでしょう。位置データがなければ距離を計算できないため、0675だけでは仕組みが完成しません。一方、位置登録の方法があっても、並べ替え規則が採用されなければ現在のリーダー順は変わりません。
提案段階であり実装・有効化済みではない
SIMDはSolanaのプロトコル改善を議論し、状態を追跡する文書です。番号が付いて公開されたことは、内容が本番で稼働したことを意味しません。採択、クライアントへの実装、複数実装間の互換性確認、十分な採用率、機能ゲートによる有効化は別々の工程です。
そのため、記事やSNSで「提案された」「分析された」「実装コードがある」「有効化された」という表現を見たら、同じ段階だとまとめないことが重要です。本稿の基準日では、29.1msという結果も実運用の実績ではなく、提案を評価するための試算として扱います。
従来のリーダースケジュールと交代遅延の基礎
まなぶ「クリプ先生、リーダーってネットワークをずっと支配する人なんですか？」
クリプ「違うよ。担当はスロットごとに交代するんだ。あらかじめ決まった担当表がリーダースケジュールだと考えると分かりやすいよ。」
リーダーは、担当スロットで受け取った取引を処理し、ブロックを生成してネットワークへ伝える役割です。ほかのバリデータは結果を検証し、投票します。一つの主体が恒久的にリーダーであり続けるのではなく、公開鍵とスロットの対応表に沿って担当が移ります。
スロットごとにリーダーが割り当てられる仕組み
公式用語集では、リーダースケジュールは各スロットをバリデータの公開鍵へ対応付ける列として説明されています。スロットはリーダーが台帳へ入力するための時間枠で、エポックは多数のスロットをまとめた期間です。各バリデータはエポック境界でスケジュールを更新し、どの公開鍵がいつ担当するかを共有します。
選出にはステーク加重が関係します。概念的には、より多くのステークを持つバリデータほど担当枠を得る可能性が高くなります。ただし、今回の論点は「誰が何枠を得るか」より、得られた枠が時間軸上で「どの順番に並ぶか」です。この区別が地理対応方式を読み解く中心になります。
スロット短縮で相対的に重くなる交代コスト
リーダーが交代すると、次の担当者は直前の状態やデータを受け取り、自分の処理を始め、生成物をネットワークへ広げます。この通信に固定的な時間が必要なら、スロット全体が短くなるほど、その時間が占める割合は大きくなります。
スロット短縮の公開議論では、リーダー交代に平均約60msという観測が示され、相対的な所在地によって大きく変動するとされました。これはすべての交代が60msだという保証ではなく、地理とネットワーク経路を無視できないことを示す観測です。目標スロットを400msから段階的に200msへ短くする提案では、交代・伝播・再生・投票に使える時間も同時に小さくなります。
取引経路にも関係するリーダー間の距離
Solanaのトランザクションを利用者がRPCへ送った後、その取引は現在のブロック生産者へ転送されます。非リーダーが取引を受け取った場合も、リーダーへ届ける経路が必要です。したがって、交代の遅延はバリデータ同士だけの内部問題ではなく、取引が処理対象へ届き、実行され、配信される一連の流れと関係します。
ただし、リーダー同士を近づければ利用者の体感時間が必ず同じだけ短くなるわけではありません。利用者からRPCまでの距離、RPCからリーダーまでの経路、混雑、実行時間、投票の到着など、複数の要素が合計されるからです。29.1msを個別取引の確約値として扱えない理由もここにあります。
割当数を変えずにリーダーの順序だけを並べ替える仕組み
新方式を簡単な例で考えます。従来の抽選結果が「東京、フランクフルト、東京、アムステルダム」の順で、各バリデータに一枠ずつ割り当てられたとします。地理対応方式は、条件が合えば「東京、東京、フランクフルト、アムステルダム」のように近い担当をまとめます。登場回数は一回ずつのままで、移動するのは順序です。
実際の設計は都市名の単純な分類ではなく、登録位置とステーク分布を使って近接範囲を構成します。また、同じ地域を無制限に続ければよいわけではありません。遅延短縮と集中リスクの釣り合いを取るため、グループの範囲と連続させる長さをパラメータで制御します。
SIMD-0674でバリデータの位置情報を登録する
SIMD-0674は位置コードと座標の登録・更新方法を定めます。この情報は、物理的な距離を推定し、どのリーダーを近いと扱うかの入力になります。運用上は拠点移転や設備変更もあり得るため、初回登録だけでなく更新手順も欠かせません。
一方、この位置は自己申告です。資料上、申告地点に機器が本当に存在することを暗号学的に証明する仕組みではありません。署名によって「そのバリデータがその情報を登録した」ことは確認できても、「現実世界でその座標にいる」ことまでは同じ方法で証明できない、という境界があります。
SIMD-0675で近いリーダーを連続させる
SIMD-0675は、位置情報から近接する候補をまとめ、一定数のリーダーを連続させます。前後の担当者が物理的・ネットワーク的に近ければ、役割の受け渡しにかかる通信時間を縮められる可能性があります。ここで最適化の対象になるのは主にリーダー交代のハンドオフです。
地理的な距離と実際の通信遅延は完全には一致しません。海底ケーブル、経路制御、データセンター間接続、混雑などにより、地図上で近くても遠回りする場合があります。公式分析もモデルに基づくため、採択後には実測で効果を確かめる必要があります。
ステーク加重の割当窓数は維持される
提案が維持するのは、従来のステーク加重抽出で各バリデータが得た割当窓数です。順序変更によって、あるバリデータの一エポック中の担当回数を増やし、別のバリデータから枠を奪う設計ではありません。この点は割当面の公平性を考えるうえで重要です。
ただし、担当数が同じならあらゆる影響が同じ、とは限りません。どの時間帯に誰の前後で担当するかが変われば、通信条件、取引到着、連続障害の影響、MEVや検閲に関する評価が変わり得ます。「数は同じ」と「性質も同じ」を混同しないようにしましょう。
29.1ms短縮の効果と4.3秒の地域持続という交換条件
公式分析の代表例では、σ=10%、γ=7の設定で平均ハンドオフが29.1ms改善しました。同じ条件で地域持続スコアは平均5.4窓、時間換算で約4.3秒増えました。前者だけを成果、後者を注釈として扱うのではなく、同じ設定から生まれる一組の結果として読む必要があります。
6,250の合成ネットワークで行った感度分析
分析は現状の124地点を基礎に、6,250の合成ネットワークを生成して行われました。複数の仮想的な分布で試すことで、一つの現状スナップショットだけに依存せず、設定変更への反応を調べる狙いがあります。
それでも、合成ネットワークは本番そのものではありません。地点とステークの作り方、距離から遅延を推定する方法、観測時点の分布に結果が依存します。シミュレーションは比較には有用ですが、将来の性能を保証するものではありません。
σ=10%・γ=7で平均29.1msを短縮
29.1msは、ベースラインと地理対応の並べ替えを比較した平均ハンドオフ改善です。γ=50というより強い並べ替えで得られる改善の86%に、γ=7で到達したと報告されています。少ない連続窓で改善の大部分を得られる可能性が、3〜7窓を候補とする理由の一つです。
ただし、これは「Solanaのスロットが29.1msになる」「確認時間が29.1msになる」「すべての利用者が29.1ms得をする」という意味ではありません。交代時の一要素に関する平均差であり、端末からRPCまでを含むエンドツーエンドの取引時間とは測定対象が異なります。
提案直後に報じられた初期試算では、平均ハンドオフが36.2msから17.0msへ短くなったとされました。この差は約19.2msですが、後の公式分析が示す29.1msとは、用いたデータや設定、比較対象が同一とは限りません。複数の記事に異なる数字が出てきたときは、大きい方だけを選ばず、試行の目的と条件を照合する必要があります。
また、「平均ハンドオフ」という言葉の分母にも注意が必要です。近距離の交代が多数あれば平均は下がりますが、遠隔地域へ切り替わる場面が残る可能性はあります。利用者の体験やネットワークの安全性を評価するには、平均値とともに遅い側の分布、地域間の差、スキップされたスロットの比率を見ることが欠かせません。
地域持続は平均5.4窓（分析上の連続区間の単位）・約4.3秒増加
同じ設定では、同一地域が続く度合いを示す地域持続スコアが平均5.4窓増え、時間換算で約4.3秒の増加とされました。数秒は短く見えるかもしれませんが、ブロックチェーンでは複数の担当が連続する区間です。その間に地域的な通信障害や検閲が起きた場合、影響がまとまる可能性があります。
この数値も、全ケースで必ず5.4窓増えるという上限保証ではありません。平均値は分布のばらつきを隠します。採択を評価する際には、平均だけでなく、地域別・ケース別の悪い側の結果や障害シナリオも確認したいところです。
RUN_LENGTHを増やすほど改善は飽和し集中は続く
RUN_LENGTHを大きくすると、近接リーダーをまとめる機会が増えます。しかし遅延改善は次第に飽和し、追加の一窓から得る便益は小さくなります。一方、同一地域が続くリスクは伸び続けます。この形なら、最大値を目指すより、改善曲線が折れ曲がる付近で抑える考え方が合理的です。
設定の評価では「何ms短くなるか」だけでなく、「その追加改善のために地域持続を何窓増やすか」を並べてください。速度と分散性を別々の会議で評価すると、交換条件が見えにくくなります。
STAKE_FLOORとRUN_LENGTHが決める最適化の強さ
まなぶ「STAKE_FLOORとRUN_LENGTH、名前だけでは違いが分かりません。」
クリプ「STAKE_FLOORは“どこまでを仲間の地域にするか”、RUN_LENGTHは“その仲間を何枠続けるか”を調整するつまみだよ。」
公式分析では、STAKE_FLOORをσ、RUN_LENGTHをγと表します。二つは別の役割を持ちます。σは近接グループを作る範囲に関わり、γはそのグループ内から連続して配置する窓数に関わります。どちらか一方だけを見ても最適化の強さは決まりません。
STAKE_FLOORは近接グループの必要ステークを定める
STAKE_FLOORは、ある地点の周囲を広げていったとき、グループとして必要とするステーク比率の下限です。閾値を満たすまで半径を広げるため、ステークが密集する地域では小さな範囲でまとまり、少ない地域では遠方まで含む可能性があります。
つまり、同じ10%を設定しても、世界のどこでも同じ距離の円ができるわけではありません。地域のステーク分布が設計結果へ直接影響します。分析時点でアジアのステーク比率は約10.4%とされ、10%の閾値に対する余裕は小さいと指摘できます。分布が変われば適切な閾値も変わり得ます。
RUN_LENGTHは近いリーダーを続ける窓数を定める
RUN_LENGTHは、近接グループから何窓を続けて並べるかを定めます。値を大きくすれば、近いリーダー同士の受け渡しが増え、遠距離ハンドオフを減らしやすくなります。しかし、同一地域が時間的にまとまって担当する長さも増えます。
この値は単純に大きいほど優れているものではありません。遅延改善にはやがて頭打ちがある一方、地域が続く時間は伸び続けるためです。速度を最大化するだけでなく、障害独立性や検閲耐性を含めた上限を考える必要があります。
公式分析が示した10%と3〜7窓の候補範囲
公式分析は、STAKE_FLOORを約10%、RUN_LENGTHを3〜7とする範囲を合理的な候補として示しました。これは確定設定ではなく、感度分析から見た候補です。分布、実測遅延、クライアント実装、攻撃評価が変われば見直しが必要です。
設定値だけが独り歩きしないよう、「どの時点のステーク分布か」「どの遅延モデルか」「何を最適化した結果か」を一緒に確認してください。10%や7窓は自然法則ではなく、設計上の選択肢です。
地域集中・地域障害・位置偽装で生じるリスク
まなぶ「割当数が変わらないなら、分散性も完全に同じではないんですか？」
クリプ「人数や担当数が同じでも、同じ地域が連続する時間は変わるよ。分散性には“誰が持つか”だけでなく“どこにいて、いつ続くか”もあるんだ。」
地理対応方式の論点は、長期の割当比率を保ちながら、短期の順序を意図的に偏らせる点です。台帳全体で見れば担当者の顔ぶれが同じでも、数秒単位では特定地域へ役割がまとまります。地域障害、検閲、ネットワーク分断、攻撃者の戦略を考えると、この時間的な集中は無視できません。
同一地域の連続が障害や検閲の影響を広げる
バリデータ運用と障害の事例からも分かるように、バリデータ運用と障害の事例からも分かるように、データセンター、電力網、通信事業者、国境内のネットワーク経路には共通障害があり得ます。同一地域のリーダーが連続する区間で障害が起きれば、一人の担当だけでなく複数の担当がまとめて影響を受ける可能性があります。地理的に離れたリーダーが交互に並ぶ場合より、短時間の障害独立性が下がる場面です。
検閲についても、同一の法域や事業者に近いリーダーが続くと、特定取引を含めない状態が連続する可能性を評価する必要があります。提案だけから実際の検閲発生を断定はできませんが、順序の地域相関が増える以上、独立した攻撃分析が必要です。
地域という単位も一枚岩ではありません。同じ都市に見えても、異なるデータセンターと回線を使えば障害原因を分けられる場合があります。反対に、都市が違っても同じクラウド事業者、基幹回線、電力系統へ依存していれば、見かけほど独立していないかもしれません。座標だけで耐障害性を測らず、設備と事業者の依存関係も確認する必要があります。
障害評価では、ある地域を一斉に到達不能にする試験、国際回線が遅くなる試験、位置登録が古いまま残る試験などが考えられます。通常時の平均遅延が下がったことだけで導入可否を決めず、悪条件でチェーンがどう進み、別地域へ担当が移るまで何窓かかるかを測るべきです。
自己申告の位置情報には暗号学的な証明がない
位置登録は自己申告であり、GPSの真実性やサーバーの物理所在地を合意層が自動証明するものではありません。IPアドレスもVPN、プロキシ、トンネル、複雑なネットワーク構成によって物理位置と一致しない場合があります。
したがって、登録署名だけを見て位置の正確性まで保証されたと考えてはいけません。検証手段、虚偽申告を発見した際の扱い、拠点移転時の更新期限、第三者観測との不一致をどう処理するかが実装上の課題になります。
孤立地点の偽装が連続窓獲得の攻撃面になる
位置を偽れるなら、攻撃者は並べ替えで有利になりそうな地点を選ぶ動機を持ち得ます。たとえば、孤立した地点を装い、自分が管理する複数バリデータを近接グループとして扱わせ、連続窓を得ようとする可能性が論点になります。
実際にどの程度有利になるかはアルゴリズムとステーク分布によります。しかし、これまで順序決定に使わなかった自己申告データを使えば、新しい入力操作の攻撃面が増えるのは確かです。位置の検証、異常検知、経済的な罰則や除外手順を合わせて検討する必要があります。
小規模地域では遅延改善が限定される
ステークが少ない地域では、STAKE_FLOORを満たすために探索半径が広がり、遠い地域のバリデータまで同じグループへ含まれる可能性があります。その場合、「地域でまとめる」と呼んでも、実際の通信距離は十分に短くならず、期待した改善を得にくくなります。
これは地理的に均等な恩恵ではないことを意味します。既にステークや設備が密集する地域ほど短距離グループを作りやすく、周縁地域は不利になり得ます。地域別の結果を公開し、閾値が特定地域への移転誘因になっていないか追う必要があります。
低遅延の追求が地理的集積を促す可能性
低遅延が報酬やブロック生成の安定性へ結び付くなら、運用者は有力な拠点の近くへ設備を移す動機を持ちます。地理対応スケジュールが直接移転を命令しなくても、性能差が経済的誘因になる可能性があります。
研究では、ノード数やステーク分散だけでは地理的な障害独立性を十分に表せないと論じられています。異なる事業者に分散していても、同じ都市、同じクラウド、同じ電力・回線へ依存すれば共通障害が残ります。評価指標には運営主体、ステーク、クライアントだけでなく、都市、施設、ネットワーク事業者も加えるべきです。
今後の実装状況と効果を確認する方法
確認事項は読者によって異なります。一般読者はSIMDの状態と機能ゲート、運用者はそれに加えてRPC・CLIによる遅延分布と生成実績を見ます。文書の公開から本番稼働までには段階があり、各段階の資料を混同しないことが大切です。
SIMDの承認状況と機能ゲートを分けて追う
まずSIMDリポジトリで0674と0675の状態、レビュー、仕様変更を確認します。次にAgaveなどのクライアントで実装が取り込まれたか、他のクライアントが互換実装を備えたかを追います。最後に、必要バージョンの採用率と機能ゲートの予定を確認します。
実装コードが存在しても、機能ゲートが有効にならなければ本番の規則は変わりません。逆に、有効化が近づけば、位置登録の手順、未登録バリデータの扱い、ロールバック条件、監視項目など運用情報が重要になります。
RPCでリーダー予定と割当・生成実績を確認する
Solanaの公開RPCには、指定エポックのリーダースケジュールを返すgetLeaderSchedule、指定範囲のリーダー列を返すgetSlotLeaders、エポック設定を返すgetEpochScheduleがあります。これらを使えば、公開されたスロットとバリデータIDの対応を確認できます。
さらにgetBlockProductionは、指定範囲の割当数と実際のブロック生成数を返します。提案が将来有効になった場合、予定表の地理的な並び、割当数が維持されているか、地域別の生成実績に変化があるかを検証する材料になります。ただし、公開鍵から正確な物理位置を独自に断定する際は、位置データの信頼性を別途評価してください。
比較手順は、変更前後で同じ長さの期間を取り、予定された割当、実際の生成、隣接リーダー間の推定距離、観測遅延を対応付ける形が基本です。ネットワーク全体の混雑やソフトウェア更新が同時に起きると効果を切り分けにくいため、バージョン、時刻、地域、観測点も記録します。
RPCの返値は公開された合意状態を調べる強い材料ですが、それだけで物理ネットワークの全容は分かりません。複数の観測点からの遅延測定や、バリデータが公開する運用情報と組み合わせ、単一の観測サービスに依存しないことが望まれます。
CLIでバリデータ運用データを確認する
運用者はSolana CLIのleader-schedule、block-production、validatorsなどを使って、リーダー予定、生成状況、バリデータ情報を確認できます。RPCとCLIはニュースの表現を検証する入口になります。
確認するときは、一日分の平均だけでなく、エポック境界、地域別の連続長、失敗した割当、遅延分布を保存すると比較しやすくなります。変更前の基準値がなければ、変更後に速くなったのか、単にネットワーク条件が違ったのか判断しにくいためです。
シミュレーションと本番実測を混同しない
本番評価では、平均ハンドオフだけでなく、中央値、上位パーセンタイル、地域別の差、ブロック生成成功率、投票遅延、フォークやスキップ、障害時の回復を確認したいところです。平均が改善しても、一部地域の悪化や極端なケースが隠れることがあります。
また、ステーク分布は時間とともに変わります。分析時に妥当だった10%の閾値が将来も適切とは限りません。定期的に分布を再計測し、設定を固定したままにしない仕組みが必要です。
この提案はSOLの価格やバリデータ収益の上昇を示す資料ではありません。性能改善の可能性は、需要、手数料、価格、投資成果を保証しません。投資判断をする場合は、技術提案と市場価格の材料を分け、損失リスクも含めて検討してください。
まとめ：三つの判断軸で提案を読む
判断軸は三つです。第一に、2026年10月16日時点では未実装の提案であること。第二に、29.1msは個別取引の保証ではなく、σ=10%・γ=7のシミュレーションにおける平均ハンドオフ改善であること。第三に、その設定では地域持続が平均5.4窓（分析上の連続区間の単位）、約4.3秒増えることです。
割当数を保つ設計でも、時間上の集中は変わります。採否は速さだけでなく、約4.3秒の集中、自己申告位置の悪用、共通障害や長期的な拠点集中を許容できるかで評価してください。
最終検証日：2026年10月16日。本稿は公開技術資料に基づく一般的な解説です。仕様や提案状態は変更され得るため、最新のSIMDと機能ゲート情報を確認してください。
