🤖 新着：Quicknode AIクックブック AIプログラミングの10の実証済みレシピ エージェント.
レシピを見る SOC 2 タイプ II 認証取得・ISO 27001
回答>Web3インフラストラクチャのアーキテクチャについて学ぶ>Web3インフラの仕組み // Tags
Web3インフラストラクチャdAppアーキテクチャ
by 要約：Web3インフラストラクチャとは、アプリケーションがブロックチェーン ネットワークからデータを読み書きできるようにする一連のツール、サービス、およびプロトコルのことです。 単一の企業が管理する中央集権型データベースに依存する従来のWebアプリケーションとは異なり、Web3アプリケーション（dapps）はブロックチェーン を「真実の源」として利用し、それと連携するために専用のインフラストラクチャスタックを必要とします。このスタックには、ユーザー での認証やトランザクションの署名を行うためのウォレット接続、ブロックチェーン ノードとの通信を行うためのRPCエンドポイント、オンチェーン のデータを検索可能にするためのインデクサー、大容量ファイル用の分散型ストレージ、そしてスケーリングのためのレイヤー2ネットワークが含まれます。ブロックチェーン 上で開発を行う開発者にとって、これらの要素がどのように組み合わさっているかを理解することは不可欠です。
わかりやすい説明
従来のWebアプリケーションのアーキテクチャは単純明快です。ユーザー がブラウザを起動し、ブラウザがWebサーバーからフロントエンドを読み込み、フロントエンドがバックエンドAPIと通信し、バックエンドがデータベースからデータを読み書きします。このアプリケーションを運用する企業は、サーバー、データベース、API、そして誰が何にアクセスできるかというルールなど、すべてのレイヤーを管理しています。
Web3アプリケーションでは、中央集権型データベースの代わりにブロックチェーン が採用されています。しかし、ブロックチェーン はデータベースではありません。これらに対してSQLクエリを実行することはできません。標準的なデータベースドライバを使って接続することもできません。また、秘密鍵を使用してAPIを呼び出すことで、by データを書き込むこともできません。ブロックチェーン とのやり取りには、根本的に異なるインフラストラクチャスタックが必要であり、そのスタックを理解することが、本番環境レベルのdappを構築するための第一歩となります。
根本的な違いはトランザクションモデルにあります。従来のアプリでは、バックエンドが独自の認証情報を使用してデータベースに書き込みを行います。一方、Web3アプリでは、ユーザー が、自身のウォレットを通じて、自身の秘密鍵でトランザクションに署名し、ブロックチェーン by に書き込みを行います。アプリケーションはこのプロセスを仲介しますが、ユーザー のオンチェーン 状態に対して直接書き込みアクセスを行うことは決してありません。サーバー管理のデータからユーザー 管理のデータへのこの移行こそが、Web3を「分散型」たらしめている要因であり、同時にインフラストラクチャをより複雑にしている要因でもあります。
Web3のインフラはWeb2とどう違うのか？
Web3のインフラストラクチャを理解する最もわかりやすい方法は、多くの開発者 がすでに知っているWeb2のスタックと比較することです。データの保存場所は異なり、それに応じてデータの読み書きを行う手順も変わります。
アスペクト | Web2 | Web3 |
|---|
真実の源 | 一元化されたデータベース | ブロックチェーン |
データを作成するのは誰か | 独自の認証情報を持つアプリのバックエンド | ユーザー ウォレットの署名を通じて |
アイデンティティ | ユーザー名とパスワード | ウォレットアドレス |
データへのアクセス | データベースへの直接クエリ | RPCエンドポイントとインデクサー |
ファイルの保存 | クラウドサーバー | IPFS および類似のネットワーク |
dappのアーキテクチャ
一般的な本番環境のDappは、それぞれが異なる機能を担う複数のレイヤーで構成されています。
フロントエンドはユーザー のインターフェースであり、通常はReact、Next.js、または類似のフレームワークで構築されたWebアプリケーションです。 フロントエンドは、レンダリング、ユーザー 入力、およびウォレットとのやり取りを処理します。プロバイダーAPI（ethers.jsやwagmiなど）を介してユーザー のウォレット（MetaMask、Phantomなど）に接続し、Dappがウォレットアドレスの取得、残高の表示、トランザクション署名の要求を行うことを可能にします。
ウォレットは、ユーザー の身元確認および認証の仕組みです。Web3ユーザー では、ユーザー名やパスワードでログインする代わりに、ウォレットを連携させます。 ウォレットは、ユーザー の公開アドレス（そのユーザーの身元）と、トランザクションに署名する機能（そのユーザーの承認）を提供します。dappがオンチェーン にデータを書き込む必要がある場合（トークンの送信、スマートコントラクトとのやり取り、NFTの鋳造など）、dappはトランザクションを構築し、署名のためにウォレットに送信します。その後、ウォレットは署名済みのトランザクションをネットワークにブロードキャストします。
RPCエンドポイントは、dappとブロックチェーン との間のゲートウェイです。すべての読み取り操作（残高の確認、スマートコントラクトの状態の照会、トランザクション領収書の取得）およびすべての書き込み操作（署名済みトランザクションの送信）は、RPCを経由して行われます エンドポイントを経由します。 エンドポイント は、リクエストを処理して結果を返すブロックチェーン ノードに接続します。RPCプロバイダーの選択は、アプリケーションの速度、信頼性 、およびデータの正確性に直接影響します。
バックエンド（オプションですが、本番環境では一般的です）は、ブロックチェーン に属さないオフチェーンロジックを処理します：ユーザー セッション管理、APIの集約、キャッシュ、分析、Webhookの処理、および従来のサービスとの統合などです。また、多くのdappでは、ユーザー のウォレット署名を必要としない操作（管理操作やガス不要のメタトランザクションなど）について、サーバーサイドでのトランザクション送信を管理するためにバックエンドを使用しています。
インデクサーは、生のブロックチェーン データをクエリ可能なデータベースに変換します。ブロックチェーン 自体は、サポート のような複雑なクエリを実行しません。 標準的なRPCメソッドを使用して、「by このアドレスが所有するすべてのNFTを表示して」や「今日のこのDEXでの総取引高はいくらか」といった質問をすることはできません。インデクサー（The Graphや、Quicknode Streams を使用して構築されたカスタムパイプラインなど）は、すべてのブロックを処理し、トランザクションやイベントをデコードして、その結果をSQLやGraphQLクエリに対応したデータベースに格納します。このインデックス化されたデータは、ポートフォリオの表示、取引履歴、分析ダッシュボード、検索機能の基盤となっています。
スマートコントラクトは、アプリケーションのオンチェーン ロジックです。これらは、トークンの転送、DeFi操作、NFTの鋳造、ガバナンス投票、およびその他のプログラム可能なオンチェーン の動作に関するルールを定義します。スマートコントラクトは一度デプロイされると、呼び出されるたびに決定論的に実行されます。これらは、企業のサーバーではなく、ブロックチェーン 上に存在する「バックエンドロジック」です。
Web3インフラの中核をなす要素とは何でしょうか？
アーキテクチャは様々ですが、実運用されているDappのほとんどは、同じ構成要素に依存しています。以下の表では、各レイヤーの役割と代表的な例を示しています。
レイヤー | 役割 | 例 |
|---|
ウォレット | ユーザー IDおよびトランザクションの署名 | MetaMask、Phantom |
RPCエンドポイント | チェーンへの読み取りおよび書き込みアクセス | Quicknode コアAPI |
インデクサー | オンチェーン のデータをクエリ可能にする | 「The Graph」、Streams |
分散型ストレージ | 大容量のファイルはオフチェーンに保存する | IPFS, Arweave |
スマートコントラクト | オンチェーン アプリケーションロジック | Solidityスマートコントラクト |
レイヤー2ネットワーク | 処理能力を拡大し、手数料を削減する | Arbitrum,Base |
データの読み取りと書き込み
Dappにおける読み取りパスと書き込みパスは、根本的に異なります。
データの読み取りは比較的簡単です。フロントエンド（またはバックエンド）は、残高、コントラクトの状態、ブロックの内容といった特定のデータを要求するRPCリクエストをノードに送信します。ノードは回答を検索して返します。 単純な読み取りの場合、信頼できるプロバイダーであれば、この往復処理には数十ミリ秒かかります。複雑なデータ要件（「このウォレットのすべてのトークンにわたる完全な取引履歴を表示して」など）の場合、dappはブロックチェーン に直接クエリを送信するのではなく、インデクサーのデータベースにクエリを送信します。これは、インデクサーがすでにデータの処理や構造化という手間のかかる作業を済ませてくれているためです。
データの書き込みは、もう少し複雑な手順を要します。ユーザー がアクション（トークンの交換など）を開始します。dappは、呼び出すスマートコントラクト、実行する関数、および渡すパラメータを指定してトランザクションを構築します。dappはガス代を見積もり、それをユーザー に提示します。ユーザー はウォレット内でトランザクションを確認・承認し、秘密鍵で署名します。署名されたトランザクションは、RPCを介してネットワークに送信されます エンドポイントを介してネットワークに送信されます。トランザクションはメンプールに入り、バリデーターがブロックに組み込むのを待ちます。ブロックに組み込まれると、トランザクションは確認されます。dappは確認を検知し（by のポーリングまたはWebSocketサブスクリプションのいずれか）、新しい状態を反映するようにUIを更新します。
ユーザー のウォレット、ガス料金の推定、メンプールへの伝播、バリデーターによる処理、確認の検知といった複数のステップからなるこの書き込みプロセスが、Web3での書き込みが従来のアプリでボタンをクリックするよりも遅く感じられる理由です。また、これが信頼性が高く低遅延なRPCインフラが不可欠である理由でもあります。ガス料金の推定からトランザクションの送信、確認の検知に至るまでのすべてのステップが、RPCを経由するからです エンドポイントを経由するからです。
マルチチェーン 現実
現代のDappが単一のチェーン上で動作することはほとんどありません。DeFiプロトコルは、Ethereum メインネットArbitrum 、Base 、Optimism 、Polygon などにデプロイされることがあります。NFTマーケットプレイス は、サポート 、Ethereum 、Solana 、および複数の L2 上で動作する可能性があります。ウォレットアプリは、数十のチェーンにわたる残高を表示し、同時に取引を可能にする必要があります。
このマルチチェーン な現実により、インフラストラクチャの要件は倍増します。各チェーンには、独自のRPCエンドポイント、独自のインデックス作成パイプライン、そしてチェーン固有の特性（異なるファイナリティモデル、異なるガスメカニズム、異なるトランザクション形式など）に対する独自の理解が必要です。5、10、あるいは80以上のチェーンにわたってこの複雑さを管理することは、大きな技術的課題であり、ほとんどのチーム は、by 各チェーンごとに独自のノードを運用するのではなく、インフラストラクチャプロバイダーを利用することでこの課題を解決しています。
dappを構築するには、独自のノードを稼働させる必要があるのでしょうか？
ほとんどの場合、そうではありません。マネージドRPCプロバイダーを利用すれば、ノードを運用することなく、本番環境向けのDappをリリースすることができます。独自のノードを運用すれば、最大限の制御とプライバシーを確保できますが、その一方で、サポート に記載されているすべてのチェーンについて、ハードウェアの準備、チェーンの同期、アップグレードやハードフォークへの対応、そして24時間体制での稼働状況の監視が必要となります。そのため、運用よりも製品開発に注力したいチーム にとっては、通常、「自社開発か外部委託か」という判断において、プロバイダーを選ぶ方が有利となります。 もし完全な制御を望まれる場合は、自社ノードの運用に関する当社の概要で、コストとメリットを比較検討してください。
Quicknode がWeb3インフラを支える仕組み
Quicknode dappsが依存するインフラストラクチャの基盤を提供します。Core APIは、単一のプラットフォームから80以上のブロックチェーン ネットワークにわたり、本番環境レベルのRPCエンドポイントを提供します。世界中に分散したノード、99.99%の稼働率、競合他社よりも2.5倍速い応答時間を特徴としています。これにより、開発者 は、各チェーンごとに個別のノードインフラを管理することなく、サポート 複数のチェーンを利用できます。
Quicknode Streams カスタムインデックス作成インフラストラクチャを、プッシュ型のデータパイプラインに置き換えます。このパイプラインは、フィルタリング済みのブロックチェーン データを、配信保証と自動再編成処理を備えて、データベースやデータウェアハウスに直接配信します。各チェーンごとにポーリングスクリプトを構築・維持する代わりに、Streamを設定するだけで、Quicknode がデータの抽出、フィルタリング、配信、および一貫性の維持を処理します。
より広範なDappスタックに関しては、Quicknode では、分散型ストレージ向けのゲートウェイおよびピンニング機能（IPFS ）、API機能を強化するアドオン（トークン残高、NFTデータ、DeFi分析など）（マーケットプレイス ）、およびJavaScriptやTypeScriptでの統合を効率化するSDK （Quicknode ）を提供しています。これらのツールを組み合わせることで、本番環境向けのWeb3アプリケーションの構築、スケーリング、運用を行うための包括的なインフラストラクチャプラットフォームが提供されます。
よくある質問
RPCと エンドポイント とインデクサーの違いは何ですか？
RPCは エンドポイント は、残高や単一のトランザクションなど、現在のチェーンの状態に関する直接的な問い合わせに応答します。インデクサーは、完全な履歴をデータベースに処理するため、RPCだけでは効率的に処理できない、ウォレットの全トランザクション履歴のような複雑なクエリを実行できるようになります。
Dappはバックエンドなしで動作するのでしょうか？
はい。多くのDappは完全にクライアントサイドで動作します。つまり、フロントエンドはRPCエンドポイントやユーザー のウォレットと直接通信します。バックエンドはオプションであり、キャッシュ、分析、ガス不要のトランザクションといったオフチェーン処理のために追加されます。
ユーザー は、Web3アプリでどのように認証を行うのでしょうか？
ユーザー アカウントを作成する代わりに、ウォレットを連携させます。ウォレットアドレスが本人確認の役割を果たし、メッセージや取引に署名することでそのアドレスの管理権限を証明するため、ユーザー名やパスワードの代わりとなります。
なぜ、チーム の多くはインフラプロバイダーを利用しているのでしょうか？
多数のチェーンを確実にサポートするには、それぞれのチェーンごとにノード、インデクサー、ストレージを運用・保守する必要があります。プロバイダーはこれらを単一のプラットフォームに統合しており、自社で構築するよりも導入が迅速で、運用コストも抑えられます。
Web3のインフラは完全に分散化されているのでしょうか？
その一部はそうであり、一部はそうではありません。ブロックチェーンやスマートコントラクトは分散型ですが、RPCプロバイダーやフロントエンドといった支援サービスは、多くの場合、中央集権型のクラウドプラットフォーム上で稼働しています。ブロックチェーン のデータストリーミングなどのリアルタイムデータフィードも、通常はマネージドプロバイダーから提供されています。
参考資料
