アダプティブルーティング
256 Blocksがインテリジェントなプロバイダールーティングを通じて信頼性の高いブロックチェーンアクセスを保証する方法
256 Blocksは、複数のRPCプロバイダー間でリクエストを自動的にルーティングし、信頼性とパフォーマンスを最大化します。このページでは、アダプティブルーティングがどのように機能し、プロバイダーが失敗した場合に何が起こるかを説明します。
仕組み
エンドポイントにリクエストが到着すると、以下のことが行われます：
- DNSレベルのルーティングを使用して、レイテンシに基づいて最寄りのリージョン（ヨーロッパ、米国、シンガポール、または南米）にリクエストをルーティングします
- ポリシーエンジンに対してリクエストを評価します
- 重み付けスコアリングを使用してプロバイダーを選択します - スコアの高いプロバイダーが選択される可能性が高くなります
- 最後に、プロバイダーが失敗した場合の自動フェイルオーバーを伴ってリクエストを実行します
これは、RPC呼び出しでもMCP統合を使用したエージェントワークフローでも、すべてのリクエストで透過的に行われます。
プロバイダースコアリング
各プロバイダーは、2つの要因に基づいてスコアリングされます：
| 要因 | 影響 |
|---|---|
| 成功率 | 失敗したリクエストはプロバイダーのスコアに大きくペナルティを与えます |
| レイテンシ | 遅いレスポンスはスコアを下げるため、パフォーマンスが低下しているプロバイダーは自然とトラフィックが減少します |
スコアはリージョンごと、チェーンごと、プロバイダーごとに計算されます。プロバイダーはヨーロッパでは良好なパフォーマンスを発揮するかもしれませんが、シンガポールでは不調かもしれません。また、Ethereumは確実に処理できてもPolygonでは苦戦するかもしれません。
スコアは各リクエストの完了後数秒以内に更新されます。後続のリクエストは、最新のパフォーマンスデータから即座に恩恵を受けます。
劣化したプロバイダー
プロバイダーのスコアがしきい値を下回ると、一時的に利用可能なプールから削除されます。これにより、失敗する可能性が高いプロバイダーにリクエストがルーティングされるのを防ぎます。
スコアは時間とともに徐々に回復し、プロバイダーがゆっくりとプールに再参入できるようになります。これにより、回復中のプロバイダーが完全に安定する前にトラフィックで圧倒されることを防ぎます。
自動フェイルオーバー
256 Blocksは、プロバイダーのレスポンスが安全に再試行可能であることを示す場合にのみリクエストを再試行します：
| レスポンス | アクション |
|---|---|
| 2xx | 成功、レスポンスを返す |
| 401 (Unauthorized) | 次のプロバイダーで再試行（一時的な認証問題） |
| 403 (Forbidden) | 次のプロバイダーで再試行（一時的な問題） |
| 429 (Rate Limited) | 次のプロバイダーで再試行 |
| 5xx (Server Error) | 次のプロバイダーで再試行 |
| その他の4xx (Client Error) | 再試行しない - リクエスト自体が無効である可能性が高い |
| Timeout | 再試行しない（二重課金を避けるため） |
| Connection Error | 次のプロバイダーで再試行（リクエストがプロバイダーに到達していない） |
フェイルオーバーが発生すると、1つが成功するかすべてのプロバイダーが試行されるまで、スコア順に各利用可能なプロバイダーが試行されます。