Solana アプリの速度改善について、あと20msでも削りたいなら専有RPCエンドポイント + SWQoS がおすすめの理由

Solana アプリの速度改善について、あと20msでも削りたいなら専有RPCエンドポイント + SWQoS がおすすめの理由

2025.09.13
高速なトレードやアプリケーションの現場では、20msでも決定的な違いを生みます。専有RPCエンドポイントと共有RPCエンドポイントには仕組みの違いがあり、この20msは決して埋まりません。本記事では、その理由と、すべてを解決できるERPCの仕組みを解説します。

httpを使うことで20msを削減できる

エンドポイントのURLに「https」と付いていると思います。この「s」はTLS/SSLを意味し、通信を暗号化して安全を確保しています。ただし、この暗号化処理にはハンドシェイクや復号化の負荷があり、およそ20msの遅延が常に加わります
つまり、RPC通信をhttpsではなくhttpで行えば、この20msを根本的に削ることができます。Solanaのようにブロックオークションが50ms前後で決まる環境では、この差は決定的です。

共有でhttpを使えない理由

「では共有エンドポイントでもhttpを使いたい」と考える方がいるかもしれません。結論から言うと、それは不可能です。
共有環境でhttpを許すと、通信は暗号化されないため、中間者攻撃による盗聴や改ざん、署名済みトランザクションの乗っ取りといった深刻なリスクが発生します。悪意ある第三者が同じ共有エンドポイントを経由するだけで、あなたの送信した取引が改ざんされる可能性が現実化してしまうのです。
このため、共有エンドポイントは必ずTLS/SSLを使う必要があります。弊社の共有RPCは、この制約の中で最速を目指して設計されていますが、TLSの20msを消すことは設計上できません。

専有でhttpを使えば20ms削減できる

専有RPCエンドポイントは、利用者が特定のクライアントだけに限定されます。そのため、TLSを必須にせず、http直結で通信を行える設計が可能になります。
これにより、20msの短縮を確実に実現できます。人数による混雑や攻撃リスクを度外視しても、専有と共有の仕組みの差で必ず埋まらないのがこの20msです。

それでも残るSWQoSの課題

しかし、速さだけでは不十分です。Solanaには Stake-weighted QoS(SWQoS) という仕組みがあり、ステークによる信頼を持たないRPCは常に20%のレーンしか利用できません。
たとえば、リーダーバリデータに直接トランザクションを送るLite-RPCのような仕組みは「速く届く」ように見えます。しかしSWQoSを持たない限り、残り80%の優先レーンを利用できないため、結果として通過率で大きく不利になります。
専有でhttpを使い20msを削減したうえで、さらにSWQoSを適用することが、速さと通過率の両立には不可欠です。
ERPCでは、専有RPCに加えてSWQoSを設定できるオプションを提供しています。
そのため「専有RPC + SWQoS」の組み合わせを利用することで、20msの短縮と高い通過率を同時に実現できます。
Solana RPC Price

Validators DAO と ERPC が解決する課題

ERPCは次の課題を解決します。
  • RPC環境で発生しがちなトランザクション失敗やレイテンシ変動
  • 多くのインフラプロバイダーによる性能制限
  • ネットワーク距離が通信品質に与える影響の大きさ
  • 小規模プロジェクトほど高品質インフラへアクセスしづらい状況
私達は、オープンソース開発を応援するSolana NFTカードゲーム Epics DAO を開発する過程で、この高品質かつハイスピードなSolana開発環境を手に入れることが非常に難しいという課題に直面しました。そこで独自にプラットフォームを構築し、その知見を基盤としてERPCやSLVを提供しています。
金融が絡むアプリケーションは特にミッションクリティカルであり、遅延やエラーは直接ユーザー体験に響きます。しかしSolanaの開発環境は非常に複雑で、従来のインターネット金融とは異なり、世界中に分散するバリデータやWeb3特有の知識体系が重なり合い、全体像を正確に把握するのが難しいという現実があります。そのため改善は進みにくく、多くのプロジェクトが遅延や不安定さに悩まされてきました。
私達は、必要とされている高性能なSolana開発環境を構築・提供することで、この状況を変え、Solanaエコシステムのさらなるユーザー体験向上に貢献していきます。ERPCも、SLVのようなオープンソース開発も、そのための一環として位置付けています。