RPC とは
注：この文書は英語の原文からの自動翻訳です。
RPC とは
RPC（Remote Procedure Call） は、アプリケーションが、相手のコンピュータのネットワークの詳細を理解する必要なしに、別のコンピュータ上で動作するプログラムにサービスを要求できるようにする通信プロトコルです。ブロックチェーンの文脈では、RPC は、ウォレット、分散型アプリケーション、ブロックエクスプローラー、その他のソフトウェアがブロックチェーンノードと通信する方法 — トランザクションの送信、残高の照会、スマートコントラクトの状態の読み取り、ブロックデータの取得 — です。
要約： RPC は、アプリケーションがブロックチェーンノードと対話するための標準的なインターフェースです — それは dApp、ウォレット、ツールをブロックチェーンネットワーク自体に接続する通信層です。
ブロックチェーンにおける RPC の仕組み
すべてのブロックチェーン node（ノード）は RPC エンドポイント — 構造化されたリクエストを受け付け、構造化されたレスポンスを返す URL — を公開しています。アプリケーションがブロックチェーンと対話する必要があるとき、このエンドポイントに RPC リクエストを送信します。
リクエスト・レスポンスのパターン
この対話は標準的なクライアント・サーバーのパターンに従います。
- リクエスト。 アプリケーション（クライアント）がノードの RPC エンドポイントにリクエストを送信します。リクエストは、どのメソッドを呼び出すかを指定し、必要なパラメータを提供します。例えば「アドレス 0x742d...bD38 の残高を取得する」または「この署名済みトランザクションをネットワークに送信する」などです。
- 処理。 ノードはリクエストを受け取り、要求された操作 — ローカルにあるブロックチェーンのコピーからの読み取り、またはネットワークへのトランザクションのブロードキャスト — を実行し、レスポンスを準備します。
- レスポンス。 ノードは結果を構造化された形式（通常は JSON）でアプリケーションに返します。
JSON-RPC
ほとんどのブロックチェーンネットワークは JSON-RPC を用います — リクエストとレスポンスが JSON オブジェクトとしてフォーマットされる軽量なプロトコルです。典型的な JSON-RPC リクエストには、メソッド名（eth_getBalance、eth_sendRawTransaction、eth_call など）とパラメータの配列が含まれます。レスポンスには結果またはエラーメッセージが含まれます。
この標準化された形式により、JSON-RPC を理解するあらゆるアプリケーションは、両側で使われるプログラミング言語やフレームワークに関わらず、同じメソッドを実装するあらゆるノードと対話できます。
よくある RPC 操作
ブロックチェーンの RPC エンドポイントは通常、次のような操作をサポートします。
- 状態の読み取り — アカウント残高、トークン保有量、スマートコントラクトのストレージ、現在のブロック番号の照会。
- トランザクションの送信 — ブロックに含めるために署名済みトランザクションをネットワークにブロードキャスト。
- スマートコントラクトの呼び出し — トランザクションを作成せずに読み取り専用のスマートコントラクト関数を実行（ガスコストなし）。
- イベントの購読 — トークン転送、コントラクトのデプロイ、新しいブロックなど、特定のオンチェーンイベントのリッスン。
- 履歴の取得 — 過去のトランザクション、ログ、ブロックデータの取得。
RPC プロバイダー
フルのブロックチェーンノードを運用するには、相当なストレージ、帯域幅、メンテナンスが必要です。多くの開発者やアプリケーションは RPC プロバイダー — ノードインフラを運用し、公開用または有料利用向けに RPC エンドポイントを公開するサードパーティのサービス — を利用します。これらのプロバイダーは、各アプリケーションが独自のノードを運用する必要なく、ブロックチェーンデータへの信頼性が高く可用性の高いアクセスを提供します。
人気の RPC プロバイダーは、複数のブロックチェーンネットワークにわたって毎日数十億のリクエストを処理し、dApp エコシステムの基盤として機能しています。
なぜクリプト AI プロジェクトにとって重要なのか
RPC は、エンドユーザーには常に見えるわけではないとしても、すべてのブロックチェーンベースの AI プロジェクトが依存する通信層です。
スマートコントラクトとの対話。 スマートコントラクトをデプロイする AI プロジェクトは、コントラクトの状態を読み取り、関数をトリガーし、トランザクションを送信するために RPC を必要とします。プロジェクトがコンピュートタスクを分配しているのであれ、推論結果を記録しているのであれ、ステーキングを管理しているのであれ、すべてのオンチェーンの対話は RPC エンドポイントを通過します。
データの取り込み。 オンチェーンの活動 — 取引パターン、ウォレットの振る舞い、プロトコルのメトリクス — を分析する AI システムは、ブロックチェーンデータを取り込むために RPC 呼び出しに依存します。RPC アクセスの速度と信頼性は、AI 分析の品質と適時性に直接影響します。
インフラへの依存。 分散型ノードネットワークを運用する AI プロジェクトにとって、RPC 層は外部ユーザーがサービスにアクセスする方法です。分散型コンピュートマーケットプレイスはタスク送信のための RPC エンドポイントを公開し、AI 推論ネットワークは結果の配信に RPC を用います。これらのエンドポイントの信頼性が、ユーザー体験を決定します。
DecAIHub のプロジェクトカードのどこに現れるか
RPC はプロジェクトカードに独立した項目として記載されていませんが、プロジェクトのアーキテクチャのいくつかの側面を支えています。
- Main chain — すべてのメインチェーンには独自の RPC 仕様があります。チェーンの選択が、どの RPC メソッドが利用可能か、そしてアプリケーションがネットワークとどのように対話するかを決定します。
- Type — RPC インフラをサービスとして提供するプロジェクト（ノードプロバイダー、API ゲートウェイ）は、そのインフラ上の役割に基づいて分類される場合があります。
- dApp とスマートコントラクトの対話 — オンチェーンのスマートコントラクトを持つあらゆるプロジェクトは、それらのコントラクトとのすべての外部対話について RPC に依存します。
RPC だけでは証明できないこと
- 分散化 — 中央集権型の RPC プロバイダーを使うことは、アプリケーションが単一障害点に依存することを意味します。プロバイダーがダウンしたりリクエストを検閲したりすると、アプリケーションはブロックチェーンへのアクセスを失います。中央集権型の RPC ゲートウェイを通じて動作することは、アプリケーションを分散的にするわけではありません。
- セキュリティ — RPC エンドポイントは公開でも非公開でも、レート制限ありでも開放でもあり得ます。公開の RPC エンドポイントは本質的にセキュリティ保証を提供するわけではありません。機密性の高いトランザクションを送信するアプリケーションは、信頼でき認証されたエンドポイントを使っていることを確認すべきです。
- オンチェーン実行 — RPC リクエストを送信することは、操作がオンチェーンで起こることを意味しません。読み取り専用の呼び出し（
eth_call）は、トランザクションを作成せずにノード上でローカルに実行されます。RPC を通じて送信された署名済みトランザクションだけが、実際にブロックチェーンの状態を変更します。 - パフォーマンス — RPC のレスポンス時間は、ノードのハードウェア、ネットワーク状況、プロバイダーのインフラに依存します。遅い RPC 接続はブロックチェーンが遅いことを示すのではなく、過負荷の、または地理的に遠いノードを示しているのかもしれません。
混同しないでください
- API — RPC は API の一種ですが、すべての API が RPC というわけではありません。REST API、GraphQL エンドポイント、WebSocket インターフェースは代替的な通信パターンです。ブロックチェーンにおいて「RPC」は、ノードが公開する JSON-RPC インターフェースを特に指します。
- node — ノードはブロックチェーンソフトウェアを実行している実際のコンピュータです。RPC は外部アプリケーションがそのノードと通信するためのインターフェースです。ノードが作業をし、RPC が扉です。
- SDK / ライブラリ — Web3.js、Ethers.js、Web3.py のようなライブラリは、生の JSON-RPC 呼び出しを開発者にとって使いやすい関数でラップすることで RPC の対話を簡素化します。ライブラリは利便性の層であり、RPC は基盤となるプロトコルです。
- Oracle — oracle（オラクル）はオフチェーンのデータをブロックチェーンに持ち込みます。RPC はアプリケーションがオンチェーンのデータを読み書きする方法です。これらは異なる役割を果たします。oracle は外部データを取り込み、RPC はすでにオンチェーンにあるデータへのアクセスを提供します。
よくある質問
RPC を使うには独自のノードを運用する必要がありますか？
いいえ。ほとんどの開発者とアプリケーションは、ノードインフラをサービスとして運用するサードパーティの RPC プロバイダーを利用します。これらのプロバイダーは、標準的な HTTP または WebSocket 接続を介してアクセス可能な RPC エンドポイントを提供します。独自のノードを運用すれば完全な制御が得られ、サードパーティへの依存を排除できますが、相当なリソースが必要です。ほとんどのユースケースでは、評判の良い RPC プロバイダーで十分です。
RPC プロバイダーがダウンするとどうなりますか？
アプリケーションが使う RPC プロバイダーがダウンすると、アプリケーションはブロックチェーンへの接続を失います。接続が回復するか、アプリケーションが代替のエンドポイントに切り替えるまで、状態を読み取ったり、トランザクションを送信したり、イベント通知を受け取ったりできません。このため、本番のアプリケーションは、異なるプロバイダーからの複数のフォールバック RPC エンドポイントを構成することがよくあります。
RPC はブロックチェーンへのアクセスと同じですか？
RPC はブロックチェーンへのアクセスの最も一般的な方法ですが、唯一の方法ではありません。一部のアプリケーションは、GraphQL ベースのインデクサーや直接のピアツーピア接続のような代替プロトコルを用います。しかし、JSON-RPC は依然として汎用的なブロックチェーンの対話のための標準インターフェースであり、事実上すべてのウォレット、dApp、ブロックチェーンツールが舞台裏でそれを用いています。
外部リンク
- Ethereum.org — JSON-RPC API — JSON-RPC 仕様と利用可能なメソッドに関する Ethereum の公式ドキュメント。
No comments to display
No comments to display