ERPC、Solana で最速になる方法を体系化したレポート『How to be faster on Solana?』を公開 — 速さを決める「ネットワーク距離の物理」を、ライブの実データとともに可視化

ERPC、Solana で最速になる方法を体系化したレポート『How to be faster on Solana?』を公開 — 速さを決める「ネットワーク距離の物理」を、ライブの実データとともに可視化

ERPC、Solana で最速になる方法を体系化したレポート『How to be faster on Solana?』を公開 — 速さを決める「ネットワーク距離の物理」を、ライブの実データとともに可視化
ELSOUL LABO B.V.(本社:オランダ・アムステルダム、代表取締役 CEO:川崎文武)および Validators DAO が運営する ERPC は、Solana 上で「どうすれば速くなるのか」を、専門外の開発者にも一目で掴めるよう一枚に体系化したレポートページ『How to be faster on Solana?』(日本語版タイトル「Solana で最速になる方法」)を公開したことをお知らせいたします。
近年、ブロックチェーン、とりわけ Solana の上で、高頻度取引(HFT)やリアルタイムな金融インフラに取り組む開発者・チームが急速に増えています。一方で、「なぜ速くなるのか」「どうすれば速くなるのか」という最も基本的な問いに対する知識は、これまで個別の技術ブログや断片的な解説に分散しており、全体像を短時間で掴める資料はほとんどありませんでした。本レポートは、ERPC がこれまで公開してきた一連の技術記事の核心を、ひとつの連続した「物理の筋道」として整理し直したものです。
本レポートは、参加者が世界中に散らばる分散型ネットワークの上でも、ネットワークをより効率的に・より高速に利用するための、実践的な理解を共有するものです。どこで、なぜ速さの差が生まれるのか——その物理を体系立てて共有することが、Solana を含むブロックチェーン全体の効率と健全な発展に資すると、私たちは考えています。
How to be faster on Solana?(レポート): https://erpc.global/ja/how-to-be-faster/ ERPC 公式サイト: https://erpc.global/ja ERPC ダッシュボード: https://dashboard.erpc.global/ja

速さを決めるのは、コードでもマシンでもない「見えない第3の層」

「同じ戦略を回しているのに、自分の bot だけ約定が遅い」「価格はちゃんと更新されるのに、自分のトランザクションだけ通らない」「RPC を乗り換えても、何も変わらなかった」——Solana で速さを競う開発者が口にする悩みは、驚くほど共通しています。
ハードウェアとコードだけでは slot は取れない — 勝負は「タイミングと位置」で決まる
最初に疑うのは決まって「自分のコードが遅いのではないか」「マシンのスペックが足りないのではないか」です。コードやマシンの最適化は、もちろん効きます。しかし、すでにそこを十分に詰めた多くのケースで、最後まで残り、そして最も見落とされているのが、目に見えない第3の層——「Solana への、ネットワーク上の距離」です。
実行経路を十分に最適化したあと、命令単位の CPU チューニングでさらに縮められるのは、ナノ秒からせいぜい数マイクロ秒の世界です。これに対してネットワーク距離が左右するのは数百ミリ秒——桁にして約 1000 倍のレバーが、ふだん最も見落とされている層に眠っています。コードとマシンを磨き切った先で、なお残る最大の伸びしろが、3つ目の層にあります。

Solana の「速い場所」は、slot ごとに世界中を移動する

Solana では、約 400 ミリ秒ごとに slot が進み、その各 slot に「リーダー」となるバリデータが割り当てられて、その時間のブロックを作ります。リーダーは高速に切り替わり(同じバリデータが複数の slot を連続して担当することもあります)、そのリーダーに最も近いサーバーが、その slot で大きく優位に立ちます。
これは従来の高頻度取引とは決定的に異なる点です。株式や為替の HFT では、取引所のマッチングエンジンという「動かない一点」の隣にサーバーを置けば、ずっと有利でいられました。ところが Solana では、リーダーが slot ごとに世界中を移っていきます。最も速い席は、毎回どこか別の場所にあります。一度どこかに陣取れば終わり、というわけにはいきません。
本レポートでは、ERPC の Leader Slot Information API(getLeaderSlots)のライブデータで駆動する地球儀が、いま現在のリーダーと、その目まぐるしい移り変わりをそのまま映し出します。「最も速い場所は動き続ける」——これは比喩ではなく、ライブで観測できる事実です。
ライブのリーダー地球儀 — Solana のリーダーは slot ごとに世界中を移動する

距離はそのままレイテンシになる — 同一ネットワークの約 0.1ms から、大陸間の 100〜300ms まで

光ファイバーを伝わる光の速度と、経路上のルーター段数が、どんなハードウェアでも超えられない「下限」を決めます。距離は、おおよそ次のような桁で効いてきます。
  • 同一ネットワーク:約 0.1ms
  • 同一データセンター:約 0.3ms
  • 同一都市:約 1ms
  • 隣接国:約 5〜10ms
  • 大陸をまたぐ:約 100〜300ms
1 つの slot はおよそ 400 ミリ秒しかありません。大陸をまたぐ 100〜300 ミリ秒は、それだけで 1 slot の窓を食いつぶしてしまいます。リーダーが目の前にいれば窓の内側に間に合い、地球の裏側にいれば、送り出す前に、もう間に合っていない。すべての slot で速くあるとは、リーダーが降りるその場所の「近く」に、つねにいるということです。
速さは Solana への距離で決まる — 同一ネットワークの直結ルート 約 0.1ms 対 遠回りの経路
なお、レポート中の「同一ネットワーク 約 0.1ms」に対する「遠回りの経路では中継段数(ホップ=信号が通過するルーターの段数)が約 7 段に増え、遅延が約 70 倍に開く」といった対比は、近い経路と遠い経路の差を直感的に示すための概数です。実測にもとづく大きな振れ幅は、ERPC の Leader Slot Information API のライブデータに表れます。あるノードからリーダーまでの実測レイテンシは、リーダーがどこにいるか(slot)によって大きく変わり、近い slot と遠い slot とで数十倍に達する開きが観測されています。「平均レイテンシ」という 1 つの数字は、速い slot と遅い slot が交互に来ているだけのことが多く、平均はしばしば実態を覆い隠します。
また、「都市の名前」はネットワークの経路そのものではありません。同じ都市内であっても、外部トランジットや余分なホップが挟まれば、それだけで遅延は積み上がります。だからこそ、地図上の距離ではなく、実測した到達時間(ping)で最も近いノードを選ぶ必要があります。

1 つの都市では足りない — マルチリージョンで「リーダーの近く」に常駐する

Solana のバリデータが最も密集している都市は Frankfurt です。それでも、公開時点の実測スナップショットでは、Frankfurt に集まるバリデータは検証者数でも stake でも、ネットワーク全体のおよそ 4 分の 1 程度にとどまります。残るおよそ 4 分の 3 の slot は、Frankfurt 以外のどこかがリーダーになります。
距離がパケットに課すコストと、最も混む Frankfurt でもネットワーク全体の約 4 分の 1
つまり、たとえ最も混雑した一都市に最良の一台を置いたとしても、それだけでは「つねに最速」にはなれません。複数のリージョン(たとえば Frankfurt / Amsterdam / New York / Tokyo / Singapore)に常駐し、いまライブで動いているリーダーの近くで受け取り、リーダーが移るたびに引き継いでいく——これが、すべての slot で速くあるための考え方です。

トランザクションが通らないのは、「スパムレーン」に並んでいるから

速さは、サーバーの位置だけの問題ではありません。トランザクションを「どのレーンで届けるか」も、成否を分けます。
stake-weighted priority(SWQoS)— stake がなければ混雑した「スパムレーン」に並ぶ
Solana のリーダーは、トランザクションを受け取る TPU(Transaction Processing Unit)の処理能力のうち、最大で約 80% を stake-weighted priority——すなわちバリデータに committed された SOL(stake)に裏打ちされた接続に、優先的に割り当てます(SWQoS / Stake-Weighted Quality of Service)。残る約 20% を、それ以外のすべての接続が分け合います。後者は、スパムでひしめく混雑したレーンです。なお、この約 80% という配分は Solana のプロトコル仕様としてリーダー側が決めるものであり、ERPC が設定するものではありません。
リーダーに直接トランザクションを送り込むのは、一見すると最速の手のように思えます。しかし stake の裏打ちがなければ、それは混んだ約 20% のレーンに並ぶことを意味し、負荷が高まる場面ではブロックに入れないまま終わってしまいます。本質的な答えは、stake に裏打ちされた経路——staked validator と信頼関係(trusted peer)で結ばれた RPC からトランザクションを送ることです。ERPC は、その背景として、トップティアの staked validator を高品質な RPC ラインに接続して運用しています(Shinobi Performance Pool)。

ハードウェアは、フルパワーで回ってこそ意味がある

正しい場所に置いたサーバーも、その箱自体が全力で回らなければ、せっかく得た近さを活かしきれません。仮想化された VPS は、ハイパーバイザを共有するため、最も混み合う場面で「うるさい隣人」によるジッターや停滞を起こしやすくなります。専有のベアメタルにはそれがありません。Solana のバリデータが満たすべきクロックの下限は 2.8GHz です。ERPC のベアメタルは、その水準を大きく上回る 5.7GHz 級の高クロックで回り、しかも利用率を 30〜40% に保ちます——95% まで張り付いた CPU は、渋滞した道路のようにジッターを生むからです。
こうした差は、最上位のベアメタルに限った話ではありません。本レポートでは、ERPC の VPS(VPS++)と、同等スペック(いずれも AMD Turin / 4 vCPU)の大手クラウドの仮想マシンを、実際のベンチマーク(node_bench)で並べて示します。これは演出ではなく、誰もが同じ方法で再現できる「測定」です。ERPC は、配信品質や速度を主観や宣伝文句ではなく、計測で示すことを一貫して重視しています。

最後の答えは「同一ネットワーク = ゼロ距離」

ここまでの筋道がたどり着く先は、ひとつです。Solana のインフラ——RPC、バリデータ、そして Jito や Shredstream といった取引に関わるリアルタイム経路——と「同じネットワークの上」にいること。同一ネットワークであれば約 0.1ms、パケットはそもそも公共インターネットを一度も渡りません。多くの人にとっての既定値である「公共インターネット経由」こそが、多くの人が遅い理由です。ゼロ距離は、位置・マシン・stake のすべてを束ねる結論です。

ERPC — 物理が要求した最適化を、ひとつのプラットフォームで

本レポートが物理として導く一つひとつの答えに、ERPC は対応する手段を用意しています。同一ネットワーク上の VPS とベアメタル(ゼロ距離)、複数リージョン(FRA / AMS / NY / TYO / SGP)への常駐(つねに最速)、実測 ping にもとづくルーティング(地図ではなく経路で最も近いノードへ)、getLeaderSlots API(リーダーの位置を slot 単位で把握)、5.7GHz 級ベアメタルとオープンソースの SLV による調律(フルパワー)。
ERPC は、もともと私たち自身が必要としていたから生まれました。オープンソースの Epics DAO(Solana 上のカードゲーム)を運営するなかで、こうしたインフラを「買おうとしても買えなかった」ため、自分たちで作るほかなかったのです。いま、その同じ土台の上に、皆様も乗ることができます。
ERPC では、Solana RPC、WebSocket、Solana Geyser gRPC、Solana Shredstream、Direct UDP Stream(Raw Shreds)、VPS、ベアメタルサーバー、専有 RPC、SWQoS、Pyth 対応 Price API、Jet Analytics & Indexed RPC を、同一プラットフォーム上で組み合わせて利用できます。

分散型ネットワークを「より速く、より効率的に」使うために

速さには、適切なインフラ投資によって改善できる領域があります。しかし本レポートが一貫して伝えようとしているのは、「どこで、なぜ、その差が生まれるのか」を理解することこそが、本当の優位だということです。位置・経路・マシン・stake のどこで時間を失っているのかを理解すれば、あとは正しいリソースを選び、本業である戦略やコーディング、開発に集中できます。
分散型ネットワークの上でも、ネットワークは効率的に使えます。その実像を体系立てて共有することは、特定の事業者の利益を超えて、Solana を含むブロックチェーン全体の効率と発展に資するはずです。

Solana 特化インフラの研究開発と継続的な改善

ERPC の背景には、ELSOUL LABO が進める Solana 特化インフラの研究開発があります。ELSOUL LABO は、オランダ政府の研究開発支援制度 WBSO において 2022 年以降 5 年連続で承認を受けています。Solana RPC インフラ、バリデータ運用、リアルタイムデータ配信、AI エージェントによる運用・開発支援に関する研究開発を継続しており、その成果は、ERPC、SLV、SLV AI、AS200261 Solana 特化データセンターを含む各種サービスに反映されています。本レポートの公開も、こうした継続的な研究開発の延長線上にある取り組みです。ERPC は今後も、その成果を体系立てて公開し続けてまいります。

ご利用・相談について

本レポートの内容に関するご質問、ご自身の構成における速度改善のご相談、各リソースの選定や移行設計、ベンチマークに関するお問い合わせは、Validators DAO 公式 Discord にてサポートチケットを作成してください。
How to be faster on Solana?(レポート): https://erpc.global/ja/how-to-be-faster/ ERPC ダッシュボード: https://dashboard.erpc.global/ja ERPC 公式サイト: https://erpc.global/ja Validators DAO 公式 Discord: https://discord.gg/C7ZQSrCkYR
日頃より ERPC をご利用いただいているご利用者の皆様に、心より御礼申し上げます。

リンク一覧