FAQ - Direct Shreds

Q. Shreds や getBlock の出力が急に壊れた、または -32015 が返ります。何が変わったのですか？

2026 年 9 月 15 日、Solana メインネットで Transaction v1 が有効になりました。新しいワイヤーレイアウトでは、先頭にバージョンプレフィックス 0x81 が置かれ、署名はメッセージの後ろに続きます。legacy の長さプレフィックスはありません。

ShredStream / Direct Shreds / UDP Forwarding をご自身で復号している場合、bincode や solana-entry 4.2 未満のデコーダーが 0x81 を署名数と誤読し、エントリーがある地点から壊れて見えることがあります。RPC 側で maxSupportedTransactionVersion: 0 のまま getBlock / getTransaction を呼び出すと -32015 Transaction version (1) is not supported by the requesting client が返ります。getTransactionsForAddress の full モードでは同じエラーが該当行ごとに返ります。Geyser gRPC で 4.2 より前のクレートを使い raw transaction を deserialize している場合も同様に影響を受けます。ERPC の parsed JSON レスポンスを既に version 1 指定で読んでいる場合は影響を受けません。

SDK をお使いの場合は、crates.io の solana-stream-sdk 2.0.0、npm の @validators-dao/solana-stream-sdk 2.0.0、@validators-dao/solana-shreds-client 2.0.0、@validators-dao/solana-entry-decoder 2.5.0 へ更新してください。SDK 1.4.0 と @validators-dao/solana-entry-decoder 2.4.0 は v1 に対応していません。ご自身の Rust デコーダーをお使いの場合は、solana-entry を 4.2.x へ更新してください。RPC は getBlock / getTransaction の第 2 引数のオプションオブジェクト、および getTransactionsForAddress のオプションにも同じ指定を、次のように行ってください。

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Q. どのリージョンにノードを設置していますか？

現在、以下のリージョンでノードを運用しています。

Frankfurt (FRA)
Amsterdam (AMS)
London (LON)
Dublin (DUB)
New York (NY)
Chicago (CHI)
Salt Lake City (SLC)
Tokyo (TY)
Singapore (SGP)
Sydney (SYD)

ERPCでは、実際のネットワーク経路に基づいてレイテンシを計測し、直線距離ではなく実測値に基づいて最も低遅延なリージョンを自動的に選択します。この仕組みにより、ユーザー個人レベルでのレイテンシ改善だけでなく、ERPC全体としてのネットワーク効率化や攻撃耐性の向上にもつながります。

万が一、ご利用環境で最適なリージョンが自動的に選択されない場合は、ERPC Webダッシュボードにてお問い合わせください。

ERPC Webダッシュボード: https://dashboard.erpc.global/ja

Q. レイテンシが9999msと表示され、最適でないリージョンが選ばれます。どうすればよいですか？

Shreds のリージョン選択では、ERPC が以下のプロキシホストから登録済み IP へ ICMP レイテンシープローブを送信します。記載されているすべての送信元 IP からの受信 ICMP エコー要求を許可してください。ファイアウォール（ufw、クラウドファイアウォール、セキュリティグループなど）でブロックされると、測定値が 9999ms となり、最適でないリージョンが選択される場合があります。同一リージョン内の複数の IP は、それぞれ別のプローブホストです。すべての IP を許可する必要があります。

リージョン	ICMP 送信元 IP
🇳🇱 Amsterdam	`82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`151.245.186.3`
🇬🇧 London	`151.241.65.10`

遠隔の接続先が選ばれています

Shared Shreds の Far Point は、容量に限りのあるフォールバックです。各エンドポイントで同時にプロキシできるストリームは、すべてのお客様を合計して最大32本です。お客様ごとの32枠ではありません。選択した Shreds エンドポイントの近くで subscriber を動かすと、共有接続、フロー制御ウィンドウ、egress の占有時間を抑えやすくなります。共有環境の応答性を保つため、表示されているすべてのリージョンの ICMP プローブ送信元 IP アドレスを許可し、リージョン選択をもう一度実行してください。継続的な利用には、選択したエンドポイントの近くにある ERPC VPS をご検討ください。UDP Forwarding Standard では、初回設定時に利用可能なリージョンを一つ選び、受信先として有効な空欄ではない公開 IPv4 アドレスとポートを設定してください。リージョンも受信先も、後からダッシュボードで変更できます。リージョンを変更すると転送の送信元 IP が変わるため、受信側のファイアウォールで新しい送信元 IP を許可する必要があります。

選択したエンドポイントの近くに ERPC VPS を用意する · UDP Forwarding Standard を設定する Direct Shreds のクイックスタートを読む

Q. IPをホワイトリストしたのに接続できません。何を確認すべきですか？

ERPC の gRPC / Shreds エンドポイントは、IP ホワイトリストで保護された plain HTTP の port 80 を使用します。HTTPS/TLS の port 443 は使用しません。

他プロバイダのクライアント例を流用すると、:443 や HTTPS が既定になっていることがあります。ドメインだけ ERPC のものに置き換えると、port と TLS 設定が残ったままになり、接続できない原因になります。

以下のエンドポイントは例です。実際にはダッシュボードに表示される自分のエンドポイントに差し替えてください。HTTP 形式で使うか、クライアントが host と port を求める場合は port 80 を明示してください。

NG: shreds-fra6-1.erpc.global:443
OK: shreds-fra6-1.erpc.global:80
OK URL 形式: http://shreds-fra6-1.erpc.global

認証は登録済み IP アドレスで行われます。ERPC の gRPC / Shreds エンドポイントでは、特定の商品ページで明示されていない限り、x-token、token、Authorization ヘッダーを追加しないでください。

Q. WebSocketまたはGeyser gRPC (YellowStone)しか使ったことがないのですが、サンプルはありますか？

SLVを使えばすぐにShreds接続のテストやアプリ開発を始めることができます。

詳しくは以下のガイドをご覧ください。

Shreds クイックスタートガイド

Q. 2つのIPを登録したいです。

1つのサブスクリプションにつき1つのエンドポイントをご利用いただけます。2つのIPを利用したい場合は、2つのサブスクリプションをご購読ください。

Q. どのリージョンがおすすめですか？

常に一つの正解となるリージョンはありません。Solana はグローバルに動作しており、ブロックを生成するリーダーの役割は、スロットを追ってバリデータの間を巡っていきます。バリデータ数とステーク量が多いリージョンほどリーダースロットの出現頻度が高く、トランザクションの着地で有利になります。ただし、それに比例して競合トラフィックも増えるため、戦略によっては相対的に空いているリージョンの方が成果を出しやすい場合もあります。

安定したリーダースロット供給を重視するならフランクフルトや北米東海岸などのバリデータ集中エリア、特定ターゲットへの最短経路を重視するなら近接リージョン、という使い分けが基本です。まず Validators Solutions で Solana ネットワークの公開分布を把握し、そのうえで ERPC Leader Slot API と実測値を使って、単一リージョン、二拠点構成、またはグローバル展開のどれが適切か判断してください。

Q. 少なくとも ~400msのレイテンシが必要です。

~400ms以内のレイテンシを確保するために重要なポイントは以下の通りです。

ping値の現実的理解: Ping値は理想環境での数値であり、実際のストリーム通信では約5倍のレイテンシとなります。例えば、大陸間のpingが100msの場合、実際のレイテンシは約500ms程度です。そのため、~400msのレイテンシを目指す場合、必ず同じリージョン内でインフラを構築する必要があります。
- Ping値の一般的な目安:
  - 同一ネットワーク内：約0.1ms
  - プライベート接続（PNI）：約0.2ms
  - 同一データセンター：約0.3ms
  - 同一都市：約1ms
  - 隣国：約5〜10ms
  - 大陸間：約100〜300ms
平均レイテンシに惑わされない: Solanaのバリデータは世界中に分散しており、「エポック」という周期ごとにランダムにリーダースケジュールが組まれ、リーダーバリデータが変わります。平均レイテンシを目安に~400msを目指すのは現実的ではなく、自分のリージョンのバリデータスケジュールを正確に把握し、近い時間帯のスロットを特定する必要があります。常に最短のレイテンシを求める場合、すべてのリージョンにインフラを構築する必要があります。同じリージョン内であれば、ストリーム通信でも数十msのネットワークレイテンシでデータ取得が可能であり、送信も数msで実行できます。
リーダースケジュールの追跡: 地域内のリーダーバリデータスケジュールを継続的に監視するには、ERPC の Leader Slot API（getLeaderSlots） を利用するのが最適です。この API では、今後のリーダー情報、ステーク量、各バリデータの地理的位置、参考用 ping 値をリアルタイムで取得でき、最小レイテンシのトレードスロットを正確に特定できます。公開マップ型データや標準 RPC API はネットワーク全体の把握には有用ですが、実行タイミングの判断には更新頻度・精度が不足します。Leader Slot API は、ルーティングやトレード判断に必要な粒度を補います。
- ERPC Leader Slot API ドキュメント
- ERPC Webダッシュボード

Solana ネットワークデータ: Validators Solutions

Q. どのようにすればゼロブロック（ゼロスロット）トレーディングを実現できますか？

ゼロブロック（ゼロスロット）トレーディングを実現するには、より高度な戦略が必要です。主なポイントは以下の通りです。

チャンスゾーンの特定: Solana のバリデータは世界中に分散しており、すべてのスロットで最適なレイテンシを実現することは物理的に不可能です。そのため、自身のインフラが存在する地域のリーダーバリデータスケジュールを継続的に監視し、最も有利なチャンスゾーンを特定することが重要です。複数リージョンにインフラを展開することも有効です。たとえばフランクフルトはバリデータ密度が高く、リーダーに選出される頻度が多いため、トレード機会も多くなります。

ERPC の Leader Slot API（getLeaderSlots） を利用することで、公開マップ型データや標準 RPC API よりも高精度にリーダースケジュール、ステーク量、バリデータの地理情報、参考用 ping 値をリアルタイムで取得できます。これにより、チャンスゾーンをより正確に予測し、ゼロレイテンシに近いトレードを実行することが可能になります。
- ERPC Leader Slot API ドキュメント
- ERPC Webダッシュボード
専有ノードの導入: 競合と比べて優位性がない場合は、専有ノードの導入を検討してください。共用ノードは他のユーザーの影響を受けレイテンシが増大するため推奨しません。また、自分のアプリケーションと専有ノードを同じネットワーク内に設置することで、ネットワークコストを最小限に抑えることが可能です。

Q. 特定のエンドポイントを利用したいです。

低レイテンシ環境を確保するために、必ず最も近いノードが自動的に選択されます。特定のエンドポイントを指定したい場合は、そのエンドポイントに最も近い場所にサーバーを借りてテストすることを推奨します。

Q. なぜ専有エンドポイントは速いのですか？

共有エンドポイントは複数のお客様でリソースを分け合って利用しているため、トラフィック量が増えるにつれてレイテンシ（遅延）が発生しやすくなります。サーバーのリソースには物理的な限界があり、処理できる仕事量が決まっています。多くのリクエストが同時に集中すると、処理を順番に行う必要があるため、レスポンス速度が低下します。

私たちは共有エンドポイントでも様々な対策を講じてパフォーマンスを最適化していますが、専有エンドポイントでは、あなただけがそのリソースを専有できるため、他のユーザーの影響を一切受けません。その結果、常に安定した高速なレスポンスが得られます。

さらに専有エンドポイントでは、HTTPなどTLSを利用しない通信オプションを提供しています。TLSハンドシェイク(約20ms)の処理を省略することで、HTTPSと比較してさらに通信速度が向上します。

Q. ご契約後にセール価格は値上げされますか？

ご契約期間中は、契約時のセール価格を据え置きでご提供します。Solana のリアルタイム処理に耐えうる環境は世界的にも希少で、ハードウェアおよびネットワーク需要の高まりとともに販売価格は段階的に引き上げる方針です。スペックの高い構成や需要の集中するリージョンほど在庫の確保が難しくなりますので、現在のキャンペーン価格でロックインしておくことが、長期的にコストを抑えるうえで最も有利な選択肢となります。

Q. クリプト支払いをしたいです

クリプト支払いは、登録済みの請求先住所の国が EU 加盟国の場合に、ERPC Webダッシュボードから利用できます。SOL、USDC、EURC で ERPC クレジットを購入できます。

購入した ERPC クレジットを使って、ERPC の各プランを開始・継続できます。ダッシュボードでクリプト支払いを選択し、ウォレットから送金してください。ダッシュボードが送金を確認し、アカウントへクレジットを反映します。

対応国：アイルランド、イタリア、エストニア、オーストリア、オランダ、キプロス、ギリシャ、クロアチア、スウェーデン、スペイン、スロバキア、スロベニア、チェコ、デンマーク、ドイツ、ハンガリー、フィンランド、フランス、ブルガリア、ベルギー、ポーランド、ポルトガル、マルタ、ラトビア、リトアニア、ルーマニア、ルクセンブルク。

リストにない国では、クレジットカードでのお支払いをご利用ください。

ERPC Webダッシュボード

Q. ShredStream にすべてのトランザクションが含まれないのはなぜですか？

Shredsは設計上、Solanaブロックチェーン上のすべてのトランザクションを含んでいません。すべてのトランザクションを監視するには、世界中に多数のプロキシを配置し、すべてのバリデーターからShredsを受信する必要がありますが、これは実際には現実的ではありません。

通常、多くのユーザーは利用可能なデータの一部を用いて運用しています。もしユースケースが完全なデータ取得を要求し、データの損失を一切許容できない場合には、Shredsは適切ではないかもしれません。

より包括的なトランザクションの監視を求める場合、Geyser gRPCはShredsよりも高い信頼性を提供します。しかし、Solanaチェーン上で100%のデータを取得するには、実際には多数のエッジサーバーを配置する必要があり、現実的ではない可能性があります。

Geyser gRPCの信頼性は99%以上であり、私たちを含む多くのユーザーがその信頼性を確認しています。

一方、Shredsは一般的に90%以上の信頼性を提供し、全てのトランザクションを取得できるわけではありませんが、その特長はGeyser gRPCよりも高速に大部分のトランザクションを取得できる点にあります。

SolanaのTurbinやGulf Streamプロトコルについて詳しく知りたい方は、以下をご参照ください。

Q. 最強の環境を手に入れたい。

Raw Shreds をご自身の受信先へ UDP 転送したい場合は、UDP Forwarding Standard をご利用ください。ダッシュボードで、初回設定時に利用可能なリージョンを一つ選び、受信先の公開 IPv4 アドレスとポートを設定します。設定は30秒ごとの更新サイクルで反映され、Heartbeat による有効化は必要ありません。料金は 0.69 EUR/時間、398 EUR/月、3343 EUR/年です。

詳細はERPC Webダッシュボードまでお問い合わせください。

ERPC Webダッシュボード

🔗 ERPC Webダッシュボード

Q. レイテンシはどのくらいですか？

レイテンシは計測方法やご利用環境によって異なります。具体的な数値よりも、実際のご利用シナリオで必要な性能を満たすかどうかが重要です。

TypeScriptやRustを利用して簡単にレイテンシを測定できるツールを提供しています。

Q. このRPC（gRPC, Shreds）は他より速いですか？

私たちは、価格帯にかかわらず高いパフォーマンスを目指して設計・運用しており、同じ条件での比較はむしろ歓迎しています。実際の結果は、リージョンや共有・専有エンドポイントの違い、ご利用のプロトコル（WebSockets、gRPC、Shreds）、そしてクライアントのプログラミング言語によって変わります。

もし他のサービスより遅い場合は、具体的な条件や比較対象についてERPC Webダッシュボードでお知らせいただけると幸いです。原因を特定し、さらなる速度改善を行います。

ERPC Webダッシュボード