--- title: "ノードのアーキテクチャ" description: "イーサリアムノードの構成方法の概要。" lang: ja --- イーサリアムのノードは、[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサス・クライアント](/developers/docs/nodes-and-clients/#consensus-clients)の2つのクライアントで構成されています。ノードが新しいブロックを提案するには、[バリデータクライアント](#validators)も実行する必要があります。 イーサリアムが[プルーフ・オブ・ワーク (PoW)](/developers/docs/consensus-mechanisms/pow/)を使用していたときは、完全なイーサリアムノードを実行するには実行クライアントだけで十分でした。しかし、[プルーフ・オブ・ステーク (PoS)](/developers/docs/consensus-mechanisms/pos/)を実装してからは、実行クライアントは[コンセンサス・クライアント](/developers/docs/nodes-and-clients/#consensus-clients)と呼ばれる別のソフトウェアと一緒に使用する必要があります。 以下の図は、2つのイーサリアムクライアントの関係を示しています。2つのクライアントは、それぞれ独自のピア・ツー・ピア (P2P) ネットワークに接続します。実行クライアントはP2Pネットワーク上でトランザクションをゴシップしてローカルのトランザクション・プールを管理し、コンセンサス・クライアントはP2Pネットワーク上でブロックをゴシップしてコンセンサスとチェーンの成長を可能にするため、別々のP2Pネットワークが必要になります。 ![Diagram of Ethereum node architecture showing execution and consensus layers](node-architecture-text-background.png) _実行クライアントには、エリゴン、ネザーマインド、Besuなど、いくつかの選択肢があります_。 この2クライアント構造が機能するためには、コンセンサス・クライアントがトランザクションのバンドルを実行クライアントに渡す必要があります。実行クライアントはトランザクションをローカルで実行し、トランザクションがイーサリアムのルールに違反していないこと、および提案されたイーサリアムの状態の更新が正しいことを検証します。ノードがブロック生成者として選択されると、そのコンセンサス・クライアントのインスタンスは、新しいブロックに含めるトランザクションのバンドルを実行クライアントに要求し、それらを実行してグローバルな状態を更新します。コンセンサス・クライアントは、[Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md)を使用したローカルRPC接続を介して実行クライアントを駆動します。 ## 実行クライアントの役割とは？ {#execution-client} 実行クライアントは、トランザクションの検証、処理、ゴシップ、および状態の管理とEthereum Virtual Machine ([EVM](/developers/docs/evm/)) のサポートを担当します。ブロックの構築、ブロックのゴシップ、またはコンセンサスロジックの処理は担当**しません**。これらはコンセンサス・クライアントの役割です。 実行クライアントは、トランザクションのリスト、更新されたステート・トライ、およびその他の実行関連データである実行ペイロードを作成します。コンセンサス・クライアントは、すべてのブロックに実行ペイロードを含めます。実行クライアントは、新しいブロック内のトランザクションを再実行して、それらが有効であることを確認する責任もあります。トランザクションの実行は、[Ethereum Virtual Machine (EVM)](/developers/docs/evm)として知られる、実行クライアントに組み込まれたコンピューター上で行われます。 実行クライアントはまた、ユーザーがイーサリアムのブロックチェーンを照会し、トランザクションを送信し、スマートコントラクトをデプロイできるようにする[RPCメソッド](/developers/docs/apis/json-rpc)を通じて、イーサリアムへのユーザーインターフェースを提供します。RPC呼び出しは、[Web3js](https://docs.web3js.org/)や[Web3py](https://web3py.readthedocs.io/en/v5/)などのライブラリ、またはブラウザウォレットなどのユーザーインターフェースによって処理されるのが一般的です。 要約すると、実行クライアントは以下の通りです。 - イーサリアムへのユーザーゲートウェイ - Ethereum Virtual Machine、イーサリアムの状態、およびトランザクション・プールのホーム ## コンセンサス・クライアントの役割とは？ {#consensus-client} コンセンサス・クライアントは、ノードがイーサリアムネットワークと同期し続けることを可能にするすべてのロジックを処理します。これには、ピアからブロックを受信し、フォーク選択アルゴリズムを実行して、ノードが常に（バリデータの有効残高で重み付けされた）アテステーションの蓄積が最も多いチェーンに従うようにすることが含まれます。実行クライアントと同様に、コンセンサス・クライアントは独自のP2Pネットワークを持ち、それを通じてブロックとアテステーションを共有します。 コンセンサス・クライアントは、ブロックのアテステーションや提案には参加しません。これは、コンセンサス・クライアントのオプションのアドオンであるバリデータによって行われます。バリデータを持たないコンセンサス・クライアントは、チェーンの先頭に追従するだけであり、ノードが同期された状態を維持できるようにします。これにより、ユーザーは正しいチェーン上にいると確信して、実行クライアントを使用してイーサリアムとトランザクションを行うことができます。 ## バリデータ {#validators} ステーキングを行い、バリデータソフトウェアを実行することで、ノードは新しいブロックを提案するために選択される資格を得ます。ノードオペレーターは、デポジット・コントラクトに32 ETHをステークすることで、コンセンサス・クライアントにバリデータを追加できます。バリデータクライアントはコンセンサス・クライアントにバンドルされており、いつでもノードに追加できます。バリデータはアテステーションとブロックの提案を処理します。また、ノードが報酬を蓄積したり、ペナルティやスラッシングによってETHを失ったりすることも可能にします。 [ステーキングの詳細](/staking/)。 ## ノードのコンポーネントの比較 {#node-comparison} | 実行クライアント | コンセンサス・クライアント | バリデータ | | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | P2Pネットワーク上でトランザクションをゴシップする | P2Pネットワーク上でブロックとアテステーションをゴシップする | ブロックを提案する | | トランザクションを実行/再実行する | フォーク選択アルゴリズムを実行する | 報酬/ペナルティを蓄積する | | 受信した状態の変更を検証する | チェーンの先頭を追跡する | アテステーションを行う | | 状態とレシートのトライを管理する | ビーコンの状態（コンセンサスと実行の情報を含む）を管理する | 32 ETHのステーキングが必要 | | 実行ペイロードを作成する | RANDAO（バリデータの選択やその他のコンセンサス操作に検証可能なランダム性を提供するアルゴリズム）に蓄積されたランダム性を追跡する | スラッシングされる可能性がある | | イーサリアムと対話するためのJSON-RPC APIを公開する | 正当化 (justification) とファイナライゼーションを追跡する | | ## 参考文献 {#further-reading} - [プルーフ・オブ・ステーク (PoS)](/developers/docs/consensus-mechanisms/pos) - [ブロックの提案](/developers/docs/consensus-mechanisms/pos/block-proposal) - [バリデータの報酬とペナルティ](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)