ブロックチェーン インフラストラクチャの重要なコンポーネントです。分散型不変台帳とフロントエンド アプリケーション間の通信を処理します。これらの中間インフラストラクチャは、ブロックチェーン上に構築されたノードとサービス間の要求と応答を促進するメッセンジャーとして機能します。 RPC (リモート プロシージャ コール) ノードは、 RPC ノードは、米国郵政公社 (USPS) に似ており、dApp からブロックチェーンへの情報の移動を容易にします。郵便局を利用して郵便物をある地点から別の地点に届けるのと同じように、dApp はブロックチェーンにアクセスするために RPC ノードに依存しています。これらのノードがなければ、分散型アプリケーションは機能しなくなります。 RPC ノードは過去 10 年間で大幅に進化しましたが、インフラストラクチャの集中化により隠れた脆弱性が生じています。この記事では、RPC ノードの役割、集中化の危険性、および dApp を脆弱性から保護できる代替手段について説明します。 RPC インフラストラクチャの進化 リモート プロシージャ コールのアイデアは、分散型コンピュータを開発者にとって透過的にするために、コンピュータ サイエンティストが異なるマシン間で通信する方法を模索していた 1970 年代にまで遡ります。 1980 年代に、最初の RPC は Sun Microsystem によって Network File System と呼ばれて開発されました。Sun Microsystem は Open Network Computing RPC プロトコルを開発し、これはネットワーク上の異なるプログラム間の通信の標準となりました。 しかし、1990 年代初頭、Microsoft は Windows ベースのシステム上のプロセス間の通信を可能にするために、独自のバージョンの RPC を開発して実装しました。2000 年代初頭には、データのエンコードに JSON を使用する JSON RPC が導入されました。標準化されたデータの転送が容易なため、開発者やプログラマーの間では悪名高い存在となりました。 過去 10 年間で、dApp はブロックチェーン業界の重要な部分となり、RPC は迷路を完成させるために必要な完璧なインフラストラクチャとなりました。 なぜ？ ローカル関数呼び出しのように別のコンピューター上でリモート関数呼び出しを実行できる機能は、ブロックチェーン アーキテクチャに最適です。 ステートレス性と軽量性によりブロックチェーンが強化され、帯域幅とコンピューティングの制約状況で役立ちます。 RPC は、その利点から急速に普及しました。RPC は、異なる言語で記述されたアプリケーションが接続して通信できるようにするために提案されました。RPC の基本的な考え方は、別のコンピューターまたはサーバー上で、ローカル関数呼び出しのようにリモート関数呼び出しを行うことです。 長年にわたり、RPC には主に 3 つのタイプ (集中型、分散型、セルフホスト型) があり、それぞれ独自の特徴を持っています。 集中型 RPC ノードの危険性 集中型 RPC ノードは、単一のエンティティによって管理および制御されるノードです。これらの集中型ノードは、AWS (Amazon Web Services)、Microsoft Azure、Google Cloud Protocol (GCP) などの Web2 クラウド ホスティング サービスに似たモデルを持っています。 これらの集中型 Web3 RPC プロバイダーは分散型アプリケーション用のノード インフラストラクチャを維持していますが、システムを詳しく調べると、いかに集中化されているかが明らかになりました。皮肉なことに、これらの Web3 インフラストラクチャ プロバイダーは、サービスを維持するために Web2 クラウド ホスティング サーバー インフラストラクチャにも依存しています。 そのため、これらのクラウド プロバイダーで障害が発生すると、分散化されているはずの Web3 サービスでもダウンタイムが発生します。集中型 RPC ノードの例としては、Alchemy、Infura、Quicknode などがあります。 集中型 RPC ノードが Web3 インフラストラクチャにもたらす危険性を確認しましょう。 単一障害点があると、常にシステムの信頼性に影響します。単一のサーバーまたは単一のエンティティによって制御されるサーバー ネットワークは、dApp の障害につながる可能性のある重要なポイントをもたらします。 単一障害点: データがルーティングされるサーバーに障害が発生すると、ブロックチェーンと dApp 間のリンクが切断され、システムが停止します。単一障害点は、特に DeFi プラットフォームのような金融関連アプリでは、システムの信頼性に影響を及ぼします。 : 集中化された RPC ノードは、トラフィックが多いときにボトルネックになる可能性があり、これにより dApp のスケーラビリティが制限されます。単一のノードに依存しているためにネットワークが混雑すると、dApp の効率に影響し、レイテンシが増加してユーザーに影響を及ぼします。 スケーラビリティの問題 集中型システムであるため、dApp のスケーラビリティを向上させることは不可能です。 集中型ノードまたは専用ノードは脆弱性にさらされており、悪意のある個人の格好の標的になる可能性があります。データが漏洩したり操作されたりして、最終的には dApp の意思決定に影響を与える可能性があります。 セキュリティ リスクと脆弱性: さらに、プロバイダーに対する協調攻撃も簡単に実行でき、最終的には Dapp のユーザーが危険にさらされることになります。政府機関が単一の組織にアプリケーションのシャットダウンを強制することも可能です。 次に例を示します。 2022年、MetaMaskはベネズエラとイランのIPアドレスを持つユーザーによるブロックチェーン上での取引をブロックしたとされている。 これは、Web3 ウォレットで使用される集中型 RPC (Infura) によって可能になりました。 集中型 RPC ノードの障害と脆弱性のケーススタディ 集中型 RPC は安全そうに見えますが、そうではありません。それでも疑問がある場合は、集中型 RPC の過去の失敗に関するケース スタディをいくつか確認してみましょう。 インフラの事件 、コンセンサスによって提供される、web3 における最初のブロックチェーン バックエンド インフラストラクチャ サービス (IaaS) プロバイダーの 1 つです。インフラストラクチャは、99.9% の稼働率で利用可能であり、16 のブロックチェーン EVM で利用可能であるとされています。 Infura は 2020 年まで、Infura は dApp 開発の最前線のひとつとして、また暗号通貨/ブロックチェーンの大量導入をリードする存在として、ヒーローとみなされてきました。 2020年11月11日、Infuraが運営するGEthのバージョンにバグが発生したため、Infuraのサービスが中断しました。 ここでの主な問題は、Infura システムがダウンし、Infura インフラストラクチャのすべてのユーザーがブロックチェーンに接続できなかったことです。バグのためにサーバーが中断され、分散型ネットワークの背後にある集中化のリスクが明らかになりました。 数百万のアクティブ ユーザーを抱える最大の消費者向け Ethereum ウォレットである Metamask が混乱に陥りました。これはすべて、集中型 RPC プロバイダーである Infura に依存していたためです。 ネットワークアップグレード時の集中化に関する懸念 ネットワークのアップグレード/ハードフォーク中は、特に集中型インフラストラクチャ プロバイダーに依存する dAapps に関して、サービス障害に関する懸念が通常生じます。これらの懸念には次のものが含まれます。 単一障害点により、アクティビティが中断され、ダウンタイムが発生する可能性があります。 過去の例をいくつか挙げます。 の際、多くの集中型RPCプロバイダーがダウンタイムを経験しました。これらのダウンタイムの一部は、ネットワークがアップグレードされた結果です。DeFiアプリはトランザクションを処理できず、ユーザーは宙ぶらりんの状態になります。 2019年のイーサリアムイスタンブールハードフォーク 中、RPC サービス プロバイダーは接続の問題に直面し、ブロックチェーン ネットワークと同期されませんでした。ユーザーは数時間にわたって DeFi dApps にアクセスできなかったため、トランザクションが遅延したり失敗したりしました。 Polygon Heimdall のアップグレード 2021年のSolana RPCオーバーロード 2021 年に多くの障害を経験しました。悪名高い障害の 1 つは、ピーク時に集中型 RPC サービスが過負荷になったことが原因でした。パブリック ノードが過負荷になったため、ユーザーは数時間にわたって Solana Blockchain とやり取りできず、ネットワークは数時間にわたってフルサービスの停止に直面しました。 Solana は これらの顔面を手で覆うような事例やその他数え切れない事例は、ブロックチェーンの実用性に対する RPC プロバイダーの重要性を明らかにしています。多くの dApp では依然として中央集権型プロバイダーが使用されていますが (おそらく無知または無思慮から)、長年にわたって代替手段が存在してきました。 次のセクションでは、他の選択肢と、それがブロックチェーン開発にとってどのように優れた選択肢となっているかについて説明します。 DApp の分散化: 集中型 RPC ノードに代わるトップの選択肢 セルフホスト型 RPC ノード 名前が示すように、セルフホスト型 RPC ノードは、独自のハードウェアまたはクラウド インフラストラクチャでホストまたは管理するノードです。サードパーティの RPC プロバイダーに依存する代わりに、独自の RPC ノードをホストできます。ブロックチェーン ネットワークに直接アクセスし、トランザクションを検証し、ブロックチェーン データを直接クエリし、dApp と対話できます。 セルフホスト型 RPC ノードの利点は次のとおりです。 : ノードを実行すると、ノードの構成を完全に制御できるようになります。ニーズに合わせてソフトウェアをカスタマイズし、自由に更新を適用し、セキュリティを管理できます。 自律性/制御 : サードパーティの集中型ノードによくあるサービス停止やプロバイダーの問題による障害を心配する必要はありません。 信頼性 : インフラストラクチャ上でノードを実行すると、そのサービスの責任を負い、ブロックチェーン ネットワークへの低遅延アクセスが可能になります。 直接ネットワーク アクセス 自己ホスト型ノードは、中央集権型のノードよりも信頼性が高いように見えますが、欠点もあります。以下がその欠点です。 。RPC ノードをホストするには、ブロックチェーンの履歴を保存するために大量のディスク領域が必要です。RPC ノードを実行するために必要なストレージ、帯域幅、および処理能力は、膨大なものになる可能性があります。 高いリソース要件 さらに、ブロックチェーンとの継続的な同期が必要であり、これにより大量の帯域幅が消費され、負担が大きくなる可能性があります。特にトラフィック量が多い状況で情報を処理する場合、必要な処理能力も膨大になる可能性があります。 : セルフホスト型ノードを設定する方がよい選択肢のように思えますが、実際はそうではありません。ハードウェア コスト、運用コスト、機会コストが膨大になる可能性があります。 管理コストが高い 電気代、インターネット帯域幅、クラウド サービス料金 (クラウド インフラストラクチャを使用する場合) などの運用コストは、莫大な額になる可能性があります。ノードを正常に実行するには、問題を解決するための専門家の専任チームが待機している必要があります。そうしないと、数時間にわたって停止するリスクがあります。 : ブロックチェーン技術、サーバー管理、セキュリティのベストプラクティスをしっかりと理解する必要があります。ソフトウェアの更新、セキュリティパッチ、ハードウェアのアップグレードなどの定期的なメンテナンスにより、ノードが適切に動作し続けるように停止を回避します。 複雑なセットアップとメンテナンス : この問題を処理するモデルを備えたサードパーティ プロバイダーとは異なり、複数のブロックチェーンとやり取りするには、各ブロックチェーンのノードをホストする必要がありますが、これはリソースを大量に消費し、持続不可能になる可能性があります。 スケーラビリティが制限されており、マルチチェーンがサポートされていない セルフホスト型ノードは、独立性、ブロックチェーンの相互作用に対する優れた制御、プライバシーを提供します。これには多大なリソース、技術的専門知識、メンテナンスが必要であり、最強のブロックチェーン開発チームであっても不可能な場合があります。 分散型 RPC ノード 分散型 RPC は、dApp がブロックチェーンと分散的に通信できるようにするブロックチェーン サーバーです。分散型 RPC プロバイダーは、インフラストラクチャを複数のノードに分散します。これにより、単一障害点が削減され、ネットワークの安定性とスケーラビリティが向上し、レイテンシが短縮されます。 分散型RPCノードが他のノードより優れている点としては、 : ノード プロバイダーの分散ネットワークは、リクエストを処理し、クエリに応答し、ブロックチェーンと対話するために機能します。 分散ネットワーク 。単一のプロバイダーを信頼しません。リクエストは複数のプロバイダーに分散されるため、単一の当事者がデータやリクエストを完全に制御することはできません。 操作はトラストレスです : RPC ノードは同じ管轄区域内にないため、エンティティ/機関はブロックチェーンへのアクセスを簡単に検閲、ブロック、または制限することはできません。管轄区域のポリシーにより RPC インフラストラクチャがシャットダウンした場合、dApp のリクエストは別の管轄区域の他の RPC ノードにルーティングできます。 検閲耐性 : RPC サービスの分散モデルにより、サービスが停止しにくくなります。ノードがダウンしても、別のノードがそのサービスを置き換えます。これにより、ダウンタイムが短縮され、一貫した可用性が確保されます。 フォールト トレランス 課題は次のとおりです。 : 適切に設定されていない場合、分散型 RPC サービスは複数のノードを経由してルーティングされるため、遅延が発生する可能性があります。RPC ノードの分散化は簡単に冗長化される可能性があり、その結果、データが複数のサーバーを経由してルーティングされ、遅延が増加する可能性があります。 遅延 : ノードは異なるエンティティによって管理されるため、ノードが均等に保護されない可能性があります。 セキュリティ : 一貫性と信頼性の高いデータを確保することは困難な場合があります。悪意のあるノードや障害のあるノードを検出して軽減するためのメカニズムを導入する必要があります。 ノード間のコンセンサス 分散型 RPC ノードの例には次のものがあります。 dRPC、ポケットネットワーク、Ankr dApp 開発における集中化リスクを回避するためのベストプラクティス ノードプロバイダーの多様化 dRPC のような分散型 RPC ノード プロバイダーを選択すると、集中化のリスクを回避できます。分散型 RPC プロバイダーには、ロード バランサー、ノード プロバイダーの監視、善良なアクターに対するインセンティブなど、ノードが必要な機能として動作することを保証するシステムが備わっています。 たとえば、dRPC では、ノード インフラストラクチャの多様化を監視するためのダッシュボードにアクセスできます。使用するノードやその分散化の程度を直接制御することはできませんが、ダッシュボードを使用すると、ノードの分散化の程度を確認できます。 上の画像を見ると、接続が 4 つの異なる RPC ノード プロバイダー ( ) 間で分散化されていることがわかります。 は、分散化レベルの累積数を示しており、「1」が最も分散化されており、「0」が最も集中化されていることを示しています。 Besked、drpc-free、drpc-public-multiregion、p2p-validator-optimism-free 分散化指数 0.563 ノードの健全性の監視と管理 開発者は、dApp が使用する RPC ノードを監視できる必要があります。これにより、dApp の信頼性が確保されます。RPC プロバイダーがシステムを管理する方法を制御できない場合もありますが、dRPC などの分散型 RPC プロバイダーには、RPC ノード プロバイダーを監視するシステムが備わっています。 では、包括的な分析にアクセスして、dApp がインフラストラクチャとどのようにやり取りしているかを監視 ダッシュボードからエラー ログを監視することもできます。 dRPC の SaaS ダッシュボード できます。たとえば、dRPC ダッシュボードでは、選択した日に dApp によって行われたリクエストの合計数を監視したり、RPC ノードの分散化を監視したり、API キーに基づいてリクエストの分散を監視したりできます。 dRPC 分析ダッシュボードとは別に、dRPC にはノード プロバイダーを監視し、不正行為を防ぐバックエンド メカニズムがあります。これらのバックエンド メカニズムの詳細については、こちらをご覧ください。 結論 RPC ノードは、分散型アプリケーションとブロックチェーン間の通信を促進する上で重要な役割を果たします。ただし、RPC の集中化は、dApp とブロックチェーン ネットワーク全体に大きなリスクをもたらします。前述のケース スタディの以前の失敗例からもわかるように、集中型 RPC プロバイダーに依存すると、単一障害点のリスクが生じ、Web3 サービスの重大なサービス中断につながる可能性があります。 開発者には代替手段がないわけではありません。自己ホスト型の分散型 RPC は、回復力のあるアプリケーションの構築に役立つ信頼性の高いソリューションを提供します。 などの分散型 RPC を採用することで、開発者は集中化のリスクを軽減し、強力で回復力があり、検閲に耐え、安全なアプリケーションを構築できます。 dRPC
