ノードとクライアント

イーサリアムは、「ノード」と呼ばれるコンピュータの分散型ネットワークです。ノードで実行されているソフトウェアが、ブロックとトランザクションデータを検証します。 このソフトウェア・アプリケーションは「クライアント」と呼ばれ、コンピュータをイーサリアムノードにするために、必ず実行されなければならないものです。

注意: 現在、実行クライアントを単独で実行することはできません。 マージ以降、イーサリアムネットワークにアクセスするには、実行クライアントとコンセンサスクライアントの両方を実行する必要があります。

前提知識

イーサリアムクライアントの独自のインスタンスを実行する前に、ピアツーピア・ネットワークの概念とEVM の基本の理解が必要です。 まずはイーサリアム入門をご覧ください。

初めてノードを運用する場合は、まずイーサリアムノードの運用というユーザーフレンドリーな説明を確認してください。

ノードとクライアントとは

「ノード」とは、イーサリアムソフトウェアを実行している他のコンピュータに接続されているイーサリアムクライアントソフトウェアの何らかのインスタンスであり、ネットワークを形成します。 「クライアント」とは、プロトコルルールに対してデータを検証し、安全なネットワークを維持するイーサリアムの実装です。

マージを経て、イーサリアムは実行レイヤーとコンセンサスレイヤーの 2 つの要素で構成されています。 両方のレイヤーは異なるクライアントソフトウェアによって実行されています。 このページでは、これらを実行クライアントとコンセンサスクライアントと呼びます。

• 実行クライアントは(EL クライアントや実行エンジンとも呼ばれ、過去の名称は Eth1 クライアント)、ネットワークでブロードキャストされた新たなトランザクションを受け取り、EVM(イーサリアム仮想マシン)でトランザクションを実行し、すべての現在のイーサリアムデータの最新の状態とデータベースを保持する。
• コンセンサスクライアントは(ビーコンノードや CL クライアントとも呼ばれる、旧称は ETh2 クライアント)、プルーフ・オブ・ステークのコンセンサスアルゴリズムを実行し、実行クライアントからの検証されたデータに基づき、ネットワークの合意を形成する。

マージ前は、コンセンサスレイヤーと実行レイヤーは別々のネットワークでした。イーサリアム上のすべてのトランザクションとユーザーアクティビティは、現在の実行レイヤーで行われていました。 1 つのクライアントソフトウェアが、実行環境を提供しとマイナーが生成するブロックのコンセンサス検証の両方を行っていました。 コンセンサスレイヤーのビーコンチェーンは、2020 年 12 月から別個に実行されてきました。 ビーコンチェーンにより、プルーフ・オブ・ステークの導入とイーサリアムネットワークからのデータに基づくバリデータのネットワークの調整が始まりました。

マージにより、イーサリアムはこれらのネットワークを接続し、プルーフ・オブ・ステークへ移行しました。 イーサリアムの状態を検証するために、実行クライアントとコンセンサスクライアントは、同時に稼働します。

様々なソフトウェアを組み合わせたモジュラー型設計は、カプセル化された複雑さ(opens in a new tab)と呼ばれます。 このアプローチにより、マージをシームレスに実行でき、レイヤー 2 エコシステムなどの個々のクライアントを再利用することができました。

実行クライアントとコンセンサスクライアントの統合の簡略図

クライアントの多様性

実行クライアントとコンセンサスクライアントの両方は、異なるチームがさまざまなプログラミング言語で開発しています。

複数のクライアント実装が、単一のコードベースへの依存を減らし、ネットワークをより強固にします。 理想的な目標としては、どのクライアントもネットワークの大多数を占めることなく、多様性を達成し、単一障害点を減らすことです。 また、言語の多様性はより広範なデベロッパーコミュニティを招くことにつながり、デベロッパーの希望言語で開発できます。

クライアントの多様性についてもっと詳しく

これらのクライアント実装に共通しているのは、一つの仕様に則っているということです。 仕様がイーサリアムネットワークとブロックチェーンの機能を規定しており、 すべての技術的な詳細が定義されています。仕様は下記で確認することができます。

• 元々はイーサリアムイエローペーパー(opens in a new tab)
• 実行クライアントの仕様(opens in a new tab)
• コンセンサスクライアントの仕様(opens in a new tab)
• さまざまなネットワーク・アップグレードで実装されたEIP(opens in a new tab)

ネットワークのノードの追跡

イーサリアムネットワークのノードの概要をリアルタイムで提供するトラッカーが複数あります。 分散型ネットワークの性質上、これらのクローラーはネットワークの限定されたビューしか提供できず、異なる結果を報告する可能性があることに注意してください。

• Etherscan によるノードのマップ(opens in a new tab)
• Bitfly によるEthernodes(opens in a new tab)
• イーサリアムノードクローラー(opens in a new tab)
• Nodewatch(opens in a new tab): Chainsafe によるコンセンサスノードのクローリング

ノードの類型

自分でノードを実行したい場合、ノードにはいくつかの種類があり、それぞれデータの扱い方が異なります。 実際に、クライアントが実行できるノードには、ライトノード、フルノード、アーカイブノードの 3 種類があります。 また、異なる同期戦略のオプションがあり、同期時間を短縮できます。 同期とは、イーサリアムの状態についての最新情報をどれだけ迅速に取得できるかを指します。

フルノード

• 完全なブロックチェーンデータを保存(ただし、フルノードは定期的にプルーニングされており、最初のジェネシス(誕生)までさかのぼる状態は保存されていない)
• ブロック検証に参加し、すべてのブロックと状態を検証する
• フルノードからすべての状態が得られる(ただし、非常に古い状態はアーカイブノードへのリクエストから再構築)
• ネットワークに貢献し、リクエストに応じてデータを提供する

ライトノード

すべてのブロックをダウンロードするのではなく、ライトノードはブロックヘッダーをダウンロードします。 これらのヘッダーには、ブロックの内容に関するサマリー情報のみが含まれます。 ライトノードが必要とするその他の情報は、フルノードから取得します。 ライトノードは受信したデータをブロック ヘッダーの状態ルートに対して個別に検証できます。 ライトノードでは、フルノードを実行するために必要な強力なハードウェアや高帯域幅がなくても、イーサリアムネットワークに参加できます。 最終的には、ライトノードは携帯電話や組み込み機器で動作できるようになる可能性があります。 ライトノードはコンセンサスには参加せず、マイナーやバリデータにはなれませんが、フルノードと同じ機能でイーサリアムブロックチェーンにアクセスできます。

実行クライアントの Geth には、ライト同期(Light sync)(opens in a new tab)オプションがあります。 しかし、ライト Geth ノードはデータを取得する上で、フルノードに依存しています。 ライトノードへデータを提供するフルノードはほとんどなく、ライトノードはしばしばピアを見つけることができません。 現在、コンセンサスレイヤーには本番使用可能なライトクライアントは存在しませんが、開発中のクライアントはいくつかあります。

また、ゴシップネットワーク(opens in a new tab)を介してライトクライアントデータを提供する方法もあります。 ゴシップネットワークは、フルノードがリクエストに応答することなくライトノードのネットワークをサポートできるため好都合です。

イーサリアムはまだ多数のライトノードをサポートしていませんが、ライトノードのサポートは近い将来急速に発展すると予想される領域です。

アーカイブノード

• フルノードに保存されているすべてを保持し、過去の状態のアーカイブを構築する。 例えば、ブロック 4,000,000 のアカウント残高をクエリしたい場合、または簡単にかつ確実にトレースを使用してマイニングを行うことなく、自分のトランザクションセットをテストしたい場合などに必要。
• データがテラバイト単位になるため、平均的なユーザーにとってアーカイブノードは魅力的なものではないが、ブロックエクスプローラー、ウォレットベンダー、チェーン分析などのサービスに有用。

アーカイブ以外の任意のモードでクライアントを同期すると、ブロックチェーンデータがプルーニングされます。 つまり、すべての過去の状態を保存するアーカイブは存在しませんが、フルノードは必要に応じて構築できます。

イーサリアムノードを運用する必要性

ノードを運用することで、直接的にトラストレスで、かつプライベートにイーサリアムを利用できると同時に、イーサリアムをより強固にし、分散化に貢献することができます。

メリット

自分のノードを運用すると、プライベートで自己完結したトラストレスな形でイーサリアムを利用することができます。 クライアントを使って自分でデータを検証できるので、ネットワークを信頼する必要はありません。 「信頼せず検証」はブロックチェーンでよく言われるマントラです。

• ノードはすべてのトランザクションとブロックをコンセンサスルールに対して検証する。 つまり、ネットワークの他のノードに依存したり、完全に信頼する必要がない。
• 自分のノードでイーサリアムウォレットを使用可能。 ランダムなノードに自分のアドレスや残高を漏らす必要がないため、より安全かつプライベートに分散型アプリ(Dapp)を利用できる。 自身のクライアントですべてをチェックできる。 MetaMask(opens in a new tab)、Frame(opens in a new tab)、他の多くのウォレットは RPC インポート機能を提供し、自分のノードを使用できる。
• イーサリアムからのデータに依存する他のサービスを実行および自分でホスト可能 (例えば、ビーコンチェーンのバリデータ、レイヤー 2 などのソフトウェア、インフラストラクチャ、ブロックエクスプローラー、ペイメントプロセッサーなど)。
• 独自のカスタムRPC エンドポイントを提供できる。 それがコミュニティ向けに公開されたイーサリアムエンドポイント、または非公開のエンドポイントであっても、あなたのノードを他の人が使用でき、結果として中央集権的な大手プロバイダを回避できる。
• プロセス間通信(IPC)を利用してノードに接続、またはノードを書き換えプラグインとしてプログラムの読み込みが可能。 これにより、レイテンシーが低くなり、Web3 ライブラリを使用して大量のデータを処理する場合、またはトランザクションをできるだけ早く置き換える必要がある場合に(フロントランニング)、非常に有用。
• ETH を直接ステーキングでき、ネットワークの安全性に貢献し、同時に報酬を得ることができる。 始めるにはソロステーキングを参照。

ネットワークのメリット

イーサリアムの健全性、セキュリティ、運用レジリエンスにとって、ノードの多様性は重要です。

• フルノードがコンセンサスルールを強制するため、ルールに従わないブロックが受け入れられることはない。 これはネットワークのセキュリティ強化につながる(すべてのノードが完全な検証ができないライトノードの場合では、バリデータがネットワークに対して攻撃できる恐れがあるため)。
• プルーフ・オブ・ステークの暗号経済的な防御を上回る攻撃の場合、正しいチェーンを選ぶフルノードによって、社会的回復が行われる。
• ネットワークのノード数が増えることで、分散化の究極の目標である多様で堅牢なネットワークとなり、検閲耐性があり、信頼性の高いシステムになる。
• フルノードからのブロックチェーンデータに依存するライトクライアントに、ブロックチェーンデータへのアクセスを提供する。 ネットワークの使用量が高いとき、ライトノードが同期するのに十分な数のフルノードが必要。 ライトノードはブロックチェーン全体を保持せず、ブロックヘッダーのステートルートを利用してデータを検証する。 必要に応じて、ライトノードはブロックからより多くの情報のリクエストを行う。

あなたがフルノードを運用すると、イーサリアムのネットワーク全体がその恩恵を受けることになります。

自分のノードの運用

自分のイーサリアムクライアントの運用に興味がありますか?

初心者にやさしい導入方法については、ノードの運用ページで詳細を確認してください。

技術的な方向けには、自分のノードを立ち上げるを参照し、詳細やオプションを確認してください。

代替手段

自分のノードを設定するには時間とリソースがかかりますが、常に独自のインスタンスを実行する必要はありません。 この場合では、Infura(opens in a new tab)、Alchemy(opens in a new tab)、Chainstack(opens in a new tab)、またはQuikNode(opens in a new tab)のようなサードパーティーの API プロバイダーを利用できます。 あるいは、ArchiveNode(opens in a new tab)というコミュニティが資金提供しているアーカイブノードがあり、時間とリソースに余裕のない独立デベロッパーのためにイーサリアムブロックチェーンのアーカイブデータを提供しています。 これらのサービスの概要については、 ノード・アズ・ア・サービス(NaaS)で確認してください。

コミュニティでパブリックな API を持つイーサリアムノードが運用されている場合、MetaMask のようなライトウォレットをカスタム RPC を介して(opens in a new tab)コミュニティノードに向けることができ、ランダムなサードパーティを使うよりも、よりプライバシーを確保できます。

一方で、自分のクライアントを運用している場合は、必要としている友人とクライアントを共有できます。

実行クライアント(旧 「Eth1 クライアント」)

イーサリアムコミュニティは、異なるプログラミング言語で、さまざまなチームによって開発された、複数のオープンソースの実行クライアント(旧称は「Eth1 クライアント」または「イーサリアムクライアント」) を維持しています。 これにより、ネットワークがより強固になり、多様性を実現します。 理想的な目標としては、どのクライアントもネットワークの大多数を占めることなく、多様性を達成し、単一障害点を減らすことです。

この表は、いくつかのクライアントをまとめたものです。 これらはすべてクライアントテスト(opens in a new tab)に合格し、アクティブにネットワークのアップグレードで最新の状態に維持されています。

OpenEthereum は非推奨(opens in a new tab)となり、メンテナンスされていません。注意して使用し、できれば他のクライアントに切り替えてください。

サポートされているネットワークの詳細については、イーサリアムネットワークをご覧ください。

各クライアントには独自のユースケースとメリットがあります。自分の好みに基づいて選択してください。 多様性により、クライアントが異なる機能やユーザー対象に特化することができます。 機能、サポート、プログラミング言語、またはライセンスに基づいて、クライアントを選択することをお勧めします。

Besu

ハイパーレジャー・ベスは、パブリックネットワークと許可型ネットワーク向けのエンタープライズグレードのイーサリアムクライアントです。 トレースから GraphQL まで、イーサリアムメインネットのすべての機能を実行し、広範なモニタリングを行い、公開コミュニティチャンネルと企業向けの商用 SLA の両方で、ConsenSys 社によりサポートされています。 Java 実装で、Apache 2.0 ライセンスです。

機能とセットアップの詳細については、Besu の広範なドキュメント(opens in a new tab)に記載されています。

Erigon

Erigon(旧称: Turbo-Geth)は、Go Ethereum のフォークとして始まり、速度とディスク容量の効率に特化しています。 Erigon はイーサリアムを完全に再構築された実装で、現在は Go 実装ですが など他の言語でも開発中です。 Erigon は、より高速、よりモジュラー型、より最適化されたイーサリアムの実装を提供することを目的としています。 2TB 程度のディスク容量で、3 日以内にフルアーカイブノードの同期ができます。

Go Ethereum (Geth)

Go Ethereum(略して Geth) は、イーサリアムプロトコルのオリジナルの実装の 1 つです。 現在、最も普及しているクライアントであり、ユーザーやデベロッパー向けのツールの種類も豊富です。 Go 実装で、完全にオープンソースで、GNU LGPL v3 の下でライセンスされています。

詳細については、Geth のドキュメント(opens in a new tab)を参照してください。

Nethermind

Nethermind は C# .NET の技術スタックで開発されたイーサリアムの実装で、LGPL-3.0 ライセンスです。ARM を含むすべての主要なプラットフォームで稼働します。 以下のような優れたパフォーマンスを提供します。

• 最適化された仮想マシン
• 状態アクセス
• ネットワーク機能と、Prometheus/Grafana ダッシュボード、シークエンス・エンタープライズ・ロギング・サポート、JSON RPC トレース、分析プラグインなどの豊富な機能

また、Nethermind には詳細なドキュメント(opens in a new tab)、強力な開発サポート、オンラインコミュニティ、プレミアムユーザー向けの 24 時間年中無休のサポートもあります。

コンセンサスクライアント(旧「Eth2」クライアント)

コンセンサスアップグレードに対応する複数のコンセンサスクライアント(旧称: 「Eth2」クライアント) があります。 ビーコンチェーンを実行しており、マージ以降、実行クライアントにプルーフ・オブ・ステークの合意メカニズムを提供します。

Lighthouse

Lighthouse は、Apache-2.0 ライセンスの下、Rust で書かれたコンセンサスクライアントの実装です。 Sigma Prime により管理され、ビーコンチェーンの誕生以降安定し、本番リリースされています。 様々なエンタープライズ、ステーキングプール、個人からの信頼を得ています。 デスクトップ PC から高度な自動デプロイまで、幅広い環境における安全性、パフォーマンス、相互運用性を目指しています。

ドキュメントは、Lighthouse Book(opens in a new tab)にあります。

Lodestar

Lodestar は LGPL-3.0 ライセンスの下、Typescript で書かれ、本番対応のコンセンサスクライアントの実装です。 ChainSafe Systems 社により管理され、ソロステーカー、デベロッパー、研究者向けのコンセンサスクライアントの中で最も新しいものです。 Loadstar は、イーサリアムプロトコルを JavaScript で実装したビーコンノードとバリデータクライアントで構成されています。 ライトクライアントでのイーサリアムの使いやすさを向上させ、より多くのデベロッパーグループがアクセスできるようし、エコシステムの多様性にさらに貢献することを目指しています。

詳細については、Lodestar のウェブサイト(opens in a new tab)をご覧ください。

Nimbus

Nimbus は Apache-2.0 ライセンスの下、Nim で書かれたコンセンサスクライアントの実装です。 ソロステーカーやステーキングプールで使用されており、本番対応のクライアントです。 Nimbus はリソース効率を重視して設計されており、リソースに制限のあるデバイスや企業のインフラストラクチャ上でも、安定性や報酬のパフォーマンスを損なわずに簡単に実行できます。 リソース利用量が少ないということは、ネットワークに負荷がかかったときでも、クライアントの安全域が大きくなることを意味します。

Trinity により実装されています。 高速同期のように機能しますが、最新のブロックを実行するために必要なデータもダウンロードします。開始から数分以内にチェーンをクエリできます。

• 最初に状態を同期し、数分で RPC にクエリ可能
• まだ開発中で、完全に信頼できるわけではなく、バックグラウンド同期が遅くなり、RPC 応答が失敗する可能性がある

詳しくは、Nimbus のドキュメント(opens in a new tab)をご覧ください。

Prysm

Prysm は GPL-3.0 ライセンスの下、Go で書かれたフル機能のオープンソースのコンセンサスクライアントです。 オプションのウェブアプリの UI を備え、自宅でステーキングするユーザーと機関ユーザー両方向けに、ユーザーエクスペリエンス、ドキュメント、設定可能性を優先しているのが特徴です。

詳しくは、Prysm のドキュメント(opens in a new tab)をご覧ください。

Teku

Teku はオリジナルのビーコンチェーンで誕生したクライアントの 1 つです。 セキュリティ、堅牢性、安定性、使いやすさ、パフォーマンスのよくある目標に加えて、Teku はさまざまなコンセンサスクライアント標準に完全に準拠することを特に目指しています。

Teku は非常に柔軟なデプロイメントオプションを提供しています。 ビーコンノードとバリデータクライアントをシングルプロセスとして一緒に実行でき、ソロステーカーにとって非常に便利です。または、高度なステーキング操作用にノードを個別に実行することもできます。 さらに、署名キーのセキュリティとスラッシング保護のため、Web3Signer(opens in a new tab)と完全に相互運用可能です。

Teku は Java 実装で、Apache 2.0 ライセンスです。 Besu や Web3Signer を手がける ConsenSys 社のプロトコルチームによる開発です。 詳しくは、Teku のドキュメント(opens in a new tab)をご覧ください。

同期モード

ネットワークの現在のデータを追って検証するには、イーサリアムクライアントは最新のネットワーク状態と同期する必要があります。 これは、ピアからデータをダウンロードし、暗号的に完全性を検証し、ローカルのブロックチェーンデータベースを構築することで行われます。

同期モードには、さまざまなトレードオフを持つ異なるアプローチがあります。 また、各クライアントにより、同期アルゴリズムの実装に違いがあります。 実装の詳細については、常にクライアントの公式ドキュメントを参照してください。

実行レイヤーの同期モード

フル同期(Full sync)

フル同期は、ヘッダー、トランザクション、レシートを含むすべてのブロックをダウンロードし、最初のジェネシス(誕生)からの全ブロックを実行することで、ブロックチェーンの状態を段階的に生成します。

• すべてのトランザクションを検証することにより、信用する必要性を最小限に抑え、最高のセキュリティを提供
• トランザクション数が増えると、全トランザクションを処理するのに数日から数週間かかることがある

高速同期(Fast sync)

高速同期は、ヘッダー、トランザクション、レシートを含むすべてのブロックをダウンロードし、全ヘッダーを検証の上、状態をダウンロードし、検証したヘッダーに対して状態を検証します。

• 合意メカニズムのセキュリティに依存
• 同期には数時間しかかからない

軽量同期(Light sync)

軽量クライアントモード(Light client mode)は、すべてのブロックヘッダー、ブロックデータをダウンロードし、ランダムに検証を行います。 信頼できるチェックポイントからのチェーンの先端のみを同期します。

• デベロッパーへの信頼と合意メカニズムに依存し、最新の状態のみを取得
• クライアントは数分で現在のネットワーク状態で使用できるようになる

ライトクライアントの詳細(opens in a new tab)

スナップ同期(Snap sync)

スナップ同期はクライアント同期の最新のアプローチであり、Geth チームによって開発されました。 ピアが提供するダイナミック・スナップショットを使用して、中間ツリーノードをダウンロードすることなく、すべてのアカウントデータとストレージデータを取得し、ローカルでマークルツリーを再構築します。

• 現在イーサリアムメインネットでデフォルトとなっている最速の同期戦略
• セキュリティを損なうことなく、ディスク使用量とネットワーク帯域幅を大幅に節約可能

スナップ同期の詳細(opens in a new tab)

オプティミスティック同期(Optimistic sync)

オプティミスティック同期はマージ後の同期戦略で、オプトインで下位互換性(他の同期モードと互換性がある)があるように設計されており、実行ノードが確立された方法で同期できます。 実行エンジンはビーコンブロックを完全に検証せず、オプティミスティックに(楽観的に)インポートでき、最新の先頭を探し、上記の方法でチェーンの同期を開始します。 次に、実行クライアントが追いつくと、ビーコンチェーンのトランザクションの有効性をコンセンサスクライアントに通知します。

オプティミスティック同期の詳細(opens in a new tab)

チェックポイント同期(Checkpoint sync)

チェックポイント同期は、弱い主観性同期(Weak Subjectivity Sync)とも呼ばれ、ビーコンノードの同期でユーザーエクスペリエンスが優れています。 これは弱い主観性(Weak Subjectivity)の前提に基づいており、最初のジェネシスブロック からではなく、最新の「弱い主観性チェックポイント」からビーコンチェーンを同期します。 ジェネシスブロックからの同期と同様の信頼性を仮定したチェックポイント同期により、初期同期の時間を大幅に短縮できます。

実運用では、ノードがリモートサービスに接続して最新のファイナライズされた状態をダウンロードし、その時点からのデータの検証を続けます。 データを提供しているサードパーティは信頼できるものであり、慎重に選ばれる必要があります。

チェックポイント同期(opens in a new tab)の詳細

参考文献

インターネットには、イーサリアムクライアントに関する情報がたくさんあります。 ここでは、参考になりそうなリソースをいくつか紹介します。

• イーサリアム 101 - パート 2 - ノードについての理解(opens in a new tab) – 2019 年 2 月 13 日 - Wil Barnes
• イーサリアムフルノードの運用: 手間を省きたい人向けのガイド(opens in a new tab) 2019 年 11 月 7 日 - Justin Leroux

関連トピック

• ブロック
• ネットワーク

関連チュートリアル

• Gethでノードを運用 – Geth のダウンロード、インストール、実行方法。 同期モード、Javascript コンソールなど。
• MicroSD カードを挿入するだけで、Raspberry Pi 4 をバリデータノードにする – インストールガイド – Raspberry Pi 4 をフラッシュし、イーサネットケーブルを接続し、SSD ディスクを接続して、電源を入れることで、Raspberry Pi 4 を、実行レイヤー(メインネット)とコンセンサスレイヤー(ビーコンチェーン / バリデータ)の両方もしくは片方を実行するフルイーサリアムノードにする。