メインコンテンツへスキップ

このページの翻訳を行う

🌏

このページの新しいバージョンがありますが、現在は英語のみです。最新バージョンの翻訳にご協力ください。

ページを翻訳する
英語を見る

ここにバグはありません!🐛

このページは翻訳されていないため、このページは英語で表示されています。

自分のイーサリアムノードの立ち上げ

最終編集者: , Invalid DateTime
ページ編集

自分自身のノードを立ち上げ、運用することは、さまざまなメリットがあります。新しい可能性が開かれ、エコシステムのサポートへの貢献にもつながります。 このページは、自分のノードを立ち上げ、イーサリアムのトランザクション検証に参加する方法について説明します。

マージ以降、イーサリアムノードの運用には、実行レイヤー(EL)クライアントとコンセンサスレイヤー(CL)クライアントの 2 つが必要であることに注意してください。 このページでは、この 2 つのクライアントをインストール、設定、接続してイーサリアムノードを立ち上げる方法を紹介します。

前提知識

イーサリアムノードが何か、なぜクライアントを実行するのかに関する理解が必要です。 これらについては、ノードとクライアントに記載されています。

初めてノードを運用する方や、あまり技術的な知識が必要でない方法をお探しの方は、まずイーサリアムノードの運用というユーザーフレンドリーな説明を確認してください。

アプローチの選択

ノードを立ち上げる最初のステップは、アプローチを選ぶことです。 要件やさまざまな可能性に基づき、クライアントの実装(実行クライアントとコンセンサスクライアント両方)、環境(ハードウェア、システム)、クライアント設定のパラメータを選択する必要があります。

本ページではこれらについて説明し、あなたにとって最適なイーサリアムインスタンスの実行方法を見つけるサポートをします。

クライアントを選択する上で、メインネット対応している利用可能なすべての実行クライアントコンセンサスクライアントを確認し、クライアントの多様性について理解を深めてください。

クライアントの要件を確認し、ソフトウェアを自分のハードウェア、またはクラウド上で実行するかを決めます。

環境を整えたら、初心者向けのインターフェースか、高度なオプションが使用できるターミナルを使った手動かを選び、クライアントをインストールします。

ノードが実行して同期が取れたら、使用する準備が整いますが、メンテナンスには常に意識を向ける必要があります。

クライアントのセットアップ

環境とハードウェア

ローカルまたはクラウド

イーサリアムクライアントは、コンシューマーグレードのコンピュータで動作します。マイニング専用マシンのような特別なハードウェアは必要ありません。 そのため、ノードのデプロイメントには、ニーズに合わせた様々なオプションがあります。 簡単にするため、ローカルの物理マシンとクラウドサーバの両方でノードを実行することしましょう。

  • クラウド
    • プロバイダーは高可用性のサーバと静的なパブリック IP アドレスを提供
    • 専用または仮想サーバを構築するよりも容易に利用可能
    • サードパーティであるサーバプロバイダーを信頼しなければならないトレードオフが発生
    • フルノードに必要なストレージ容量により、レンタルサーバの価格が高くなることがある
  • 自分のハードウェア
    • トラストレスで主権的なアプローチ
    • 1 回限りの投資
    • 事前設定された専用マシンを購入することも可能
    • マシンやネットワークの物理的な準備、メンテナンス、トラブルシューティングが必要

どちらの選択肢も、上記のような異なるメリットがあります。 従来型のクラウドコンピューティングプロバイダに加えて、クラウドソリューションを探している場合は、ノードのデプロイに焦点を当てたサービスもあります。 例:

ホスティングされたノードのオプションについては、ノード・アズ・ア・サービスも参照してください。

ハードウェア

しかし、検閲耐性をもつ分散型ネットワークは、クラウドプロバイダに依存すべきではありません。 クラウドではなく、ローカルハードウェア上でノードを実行することが、エコシステムにとってより健全となります。 推計によると、クラウド上で動作するノードの割合が多く、単一障害点となる可能性があることが示唆されています。

イーサリアムクライアントは、デスクトップパソコン、ノートパソコン、サーバ、あるいはシングルボードコンピュータ上で動作させることができます。 パーソナルコンピュータでクライアントを実行することも可能ですが、ノード専用マシンを用意することで、プライマリコンピュータへの影響を最小限に抑えながら、パフォーマンスとセキュリティを大幅に向上させることができます。

自分のハードウェアの使用は非常に簡単です。 シンプルなオプションだけでなく、より技術的な方向けの高度なセットアップ方法も多数用意されています。 それでは、自分自身のマシンでイーサリアムクライアントを実行するための要件と方法を見てみましょう。

必要条件

ハードウェア要件はクライアントによって異なりますが、ノードは同期を維持する必要があるだけなので、通常、要件はそれほど高くありません。 より多くの計算能力を必要とするマイニングと混同しないでください。 ただし、より強力なハードウェアでは同期時間とパフォーマンスは改善します。

クライアントをインストールする前に、コンピュータに十分なリソースがあることを確認してください。 最小システム要件と推奨システム要件は以下のとおりです。

ハードウェアのボトルネックは、主にディスク容量です。 イーサリアムブロックチェーンの同期は、非常に多くの入出力を必要とし、多くのディスクスペースが必要です。 同期後も数百 GB の空き容量を確保できる、ソリッド・ステート・ドライブ(SSD)を用意することをお勧めします。

データベースのサイズと初期同期の速度は、選択したクライアント、設定、同期戦略によって異なります。

また、インターネット接続が帯域幅の上限により制限されていないことを確認してください。 ネットワークにブロードキャストされたデータが制限を超える可能性があるため、従量非制限の接続を使用することをお勧めします。

オペレーティングシステム {#operating-system}

すべてのクライアントは、Linux、MacOS、Windows などの主要なオペレーティングシステムに対応しています。 自分に最適なオペレーティングシステム(OS)を使って、通常のデスクトップまたはサーバマシンでノードを実行できます。 潜在的な問題やセキュリティの脆弱性を回避するために、お使いの OS が最新の状態になっていることを確認してください。

最小システム要件 {#minimum-requirements}
  • CPU: デュアルコア以上
  • RAM 8GB
  • ディスク空き容量 700GB
  • 帯域幅 10MB/秒以上
推奨される仕様 {#recommended-hardware}
  • 高速 CPU クアッドコア以上
  • RAM 16GB 以上
  • 高速 SSD 1TB 以上
  • 帯域幅 25MB/秒以上

選択した同期モードとクライアントによって必要容量が変わります。以下に各クライアントに必要なディスク容量の概算を記載します。

クライアントディスクサイズ(スナップ同期)ディスクサイズ(フルアーカイブ)
Geth500GB 以上12TB 以上
Nethermind500GB 以上12TB 以上
Besu800GB 以上12TB 以上
ErigonN/A2.5TB 以上
  • 注: エリゴンにはスナップ同期はありませんが、フルプルーニングが可能(約 500GB)

コンセンサスクライアントには、必要な容量はクライアントの実装や有効にした機能(バリデータスラッシャーなど)によって変わりますが、概ねビーコンデータ用にさらに 200GB を必要とします。 多数のバリデータを実行すると、帯域幅への負荷も大きくなります。 こちらの分析に、コンセンサスクライアントの要件詳細が記載されています。

プラグ・アンド・プレイ・ソリューション

自分のハードウェアでノードを実行するのに最も簡単な方法は、プラグ・アンド・プレイ・ボックスを使用することです。 事前設定されたマシンを使うと、注文、接続、実行と最も簡単に実行することができます。 何もかもが事前設定されており、自動実行され、直感的なガイドとダッシュボードでソフトウェアを監視・制御できます。

シングルボードコンピュータ

Raspberry Pi のような ARM アーキテクチャを持つシングルボードコンピュータを使用すると、イーサリアムノードを簡単かつ安価に実行できます。 Ethereum on ARMは、Raspberry Pi やその他の ARM ボード向けに、実行クライアントとコンセンサスクライアントが容易に実行できるイメージを複数提供しています。

これらのようなデバイスは、小型、価格が手頃、効率が良く、自宅でノードを運用するのに理想的な反面、性能には限界があることに留意してください。

ノードの立ち上げ

実際のクライアント設定は、自動ランチャーを使うか、または手動で直接設定できます。

上級者でない場合は、ランチャー(インストールをガイドし、クライアントのセットアッププロセスを自動化するソフトウェア)を使用することをお勧めします。 とはいえ、ターミナルの使用経験があれば、手動設定は簡単です。

ガイド付き設定

複数プロジェクトが、クライアント設定のユーザーエクスペリエンスの向上を目指しています。 ランチャーはクライアントのインストールと設定を自動的に行います。クライアントのガイド付きセットアップと監視用にグラフィック・インターフェイスを提供しているランチャーもあります。

数回クリックするだけでクライアントをインストールし、制御できる便利なプロジェクトを下記に紹介します。

  • DappNode - DappNode はベンダーからのマシンだけに提供されているのではなく、 ノードランチャーやコントロールセンターのソフトウェアは多くの機能があり、任意のハードウェアで使用可能。
  • eth-docker - Docker を使った自動設定は、簡単で安全なステーキングに焦点を当てており、ターミナルと Docker の基本的な知識が必要。少し上級のユーザー向け。
  • Stereum - SSH 接続でリモートサーバにクライアントをインストールするためのランチャー。GUI セットアップガイド、コントロールセンター、その他多くの機能搭載。
  • NiceNode - コンピュータ上でノードを実行するためのランチャー。分かりやすいユーザーエクスペリエンスが特徴。 クライアントを選択し、数回クリックするだけで開始可能。 現在、開発中。

手動でのクライアント設定

もう一つのオプションは、手動でクライアントソフトウェアをダウンロードし、確認・設定することです。 グラフィック・インターフェイスを提供しているクライアントはありますが、手動設定はターミナルの基本的なスキルが必要となりますが、はるかに汎用性があります。

前述したように、自分のイーサリアムノードを立ち上げるには、コンセンサスクライアントと実行クライアントをペアで実行する必要があります。 一部のクライアントには、他の種類のライトクライアントが含まれいるものがあり、それ以外のソフトウェアを必要とせず同期します。 しかし、完全にトラストレスな検証にはコンセンサスクライアントと実行クライアントの両方が必要です。

クライアントソフトウェアの取得

まず、希望する実行クライアントコンセンサスクライアントソフトウェアを取得する必要があります。

オペレーティングシステムとアーキテクチャに適した、実行可能なアプリケーションやインストールパッケージをダウンロードするだけです。 必ず、ダウンロードしたパッケージの署名とチェックサムを確認してください。 インストールやアップデートを簡単にするためのリポジトリや Docker イメージを提供するクライアントもあります。 クライアントはすべてオープンソースなので、ソースからビルドすることもできます。 これはより高度な方法ですが、場合によっては必要な場合があります。

クライアントごとの手順は、上記のクライアントリストにリンクされているドキュメントに記載されています。

ここでは、ビルド済みのバイナリやインストール方法が掲載されているクライアントのリリースページを紹介します。

実行クライアント {#execution-clients}

また、クライアントの多様性は実行レイヤーで問題となっていることにも注意が必要です。 マイノリティの実行クライアントの運用を検討することをお勧めします。

コンセンサスクライアント {#consensus-clients}

クライアントの多様性は、バリデータを実行しているコンセンサスノードにとって重要です。 マジョリティのバリデータが単一のクライアントを実行していると、ネットワークのセキュリティが危険にさらされます。 そのため、マイノリティクライアントを選択することをお勧めします。

最新のネットワーククライアントの使用状況を参照し、クライアントの多様性についてご覧ください。

ソフトウェアの検証 {#verifying-the-software}

インターネットからソフトウェアをダウンロードする場合は、ダウンロードしたファイルの完全性を検証することをお勧めします。 このステップは任意ですが、特にイーサリアムクライアントのような重要なインフラストラクチャの一部では、潜在的な攻撃ベクトルを認識し、回避することが重要です。 ビルド済みのバイナリをダウンロードした場合、それを信頼する必要がありますが、攻撃者が実行ファイルを悪意のあるものにすり替えるというリスクがあります。

デベロッパーはリリースしたバイナリに、デベロッパーの PGP キーで署名しているためめ、デベロッパーが作ったソフトウェアそのものを間違いなく実行していることを暗号的に検証できます。 デベロッパーが使用した公開鍵は、クライアントのリリースページやドキュメントに記載されており、そこから入手できます。 リリースされているクライアントと署名をダウンロードした後、GnuPGなどの PGP 実装を使って、簡単に検証できます。 LinuxまたはWindows/MacOSgpgを使って、オープンソースソフトウェアを検証するチュートリアルを確認してください。

ダウンロードしたソフトウェアを検証するもう 1 つの方法としては、ハッシュが(一意の暗号論的指紋)、デベロッパーによって提供されたものと一致するかどうかを確認することです。 これは PGP を使うよりもさらに簡単で、ハッシュだけを提供するクライアントもあります。 ダウンロードしたソフトウェアに対しハッシュ関数を実行し、リリースページに載っているものと比較してください。 例:

1sha256sum teku-22.6.1.tar.gz
2
39b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde
4

クライアントのセットアップ

クライアントソフトウェアのインストール、ダウンロード、またはコンパイルが完了したら、実行する準備が整い、 あとは適切な設定を行うだけです。 クライアントは豊富な設定オプションを提供しており、様々な機能を有効化できます。

まずは、クライアントのパフォーマンスやデータ使用量に大きく影響するオプションから紹介します。 同期モードとは、ブロックチェーンデータのダウンロードと検証のさまざまな方法を表します。 ノードを開始する前に、使用するネットワークと同期モードを決める必要があります。 考慮すべき最も重要なことは、クライアントに必要なディスク容量と同期時間です。 どの同期モードがデフォルトであるかをクライアントのドキュメントで確認してください。 デフォルトの同期モードが適切でなければ、セキュリティレベル、利用可能なデータ、およびコストに基づいて別の同期モードを選択します。 同期アルゴリズムとは別に、さまざまな種類の古いデータをプルーニングすることもできます。 プルーニングは、最近のブロックから利用できない状態ツリーノードなど、古いデータを削除します。

その他の基本設定オプションは、例えば ネットワークの選択(メインネットまたはテストネット)、RPC または WebSocket などの HTTP エンドポイントの有効化などです。 クライアントのドキュメントには、すべての機能とオプションが載っています。 CLI (コマンドラインインターフェース)または設定ファイルに直接、対応するフラグを指定してクライアントを実行することで、さまざまなクライアント設定ができます。 各クライアントによって多少異なりますので、設定オプションの詳細については、公式ドキュメントまたはヘルプページを必ず参照してください。

テストのため、テストネットの 1 つでクライアントを実行することを推奨します。 詳しくは、対応ネットワークの概要を参照してください。

基本設定による実行クライアントの実行例は、次のセクションに記載されています。

実行クライアントの開始

イーサリアムクライアントソフトウェアを開始する前に、環境の準備ができているか最終チェックをしてください。 以下の事項などを確認してください。

  • 選択したネットワークと同期モードを考慮した十分なディスク容量があること。
  • メモリと CPU が他のプログラムによって停止されないこと。
  • オペレーティングシステムが最新バージョンに更新されていること。
  • システムが正しい時刻と日付になっていること。
  • ルーターとファイアウォールは、リスニングポートの接続を受け付けること。 デフォルトでは、イーサリアムクライアントはリスナー (TCP) ポートとディスカバリー(UDP)ポートを使用し、ポート番号はともに 30303 がデフォルト。

最初にテストネットでクライアントを実行して、すべてが正常に動作していることを確認します。

最初にデフォルトではないクライアントを設定する必要があります。 フラグまたは設定ファイルを使って、希望の設定に変更できます。 各クライアントにより機能や設定構文は異なります。 具体的な内容については、お使いのクライアントのドキュメントを確認してください。

実行クライアントとコンセンサスクライアントは、Engine APIで指定された認証済みエンドポイントを介して通信します。 実行クライアントはコンセンサスクライアントに接続するために、既知のパスでjwtsecretを生成する必要があります。 セキュリティと安定性の理由から、両方のクライアントは同じマシン上で実行する必要があり、ローカル RPC 接続で相互に認証するので、両方のクライアントがこのパスを知っていなければなりません。 また、実行クライアントは認証された API のリスニングポートを定義する必要があります。

このトークンはクライアントソフトウェアによって自動的に生成されます。場合によっては、自分で作成することもあります。 OpenSSLを使って生成できます。

1openssl rand -hex 32 > jwtsecret
2

実行クライアントの開始

このセクションでは、実行クライアントの開始について説明します。 あくまでも基本的な設定例となりますが、以下の設定でクライアントを起動します。

  • この例では、メインネットに接続するネットワークを指定
    • テストネットのいずれか 1 つを選択して、セットアップの予備テストも実行可
  • ブロックチェーンを含むすべてのデータが格納されるデータディレクトリを定義
    • パスは必ず実際のものに変更する(例: 外付けドライブのディレクトリの指定など)
  • クライアントと通信するためのインターフェイスを有効化
    • コンセンサスクライアントとの通信で利用する JSON RPC と Engine API を含む
  • API 認証で使うjwtsecretのパスを定義
    • 例えば、/tmp/jwtsecretなど、クライアントがアクセス可能な実際のパスにする

これは基本的な例であることに注意してください。それ以外の設定はすべてデフォルトになっています。 各クライアントのドキュメントをよく読み、デフォルト、設定、機能について学びましょう。 バリデータの実行、モニタリングなど、その他の機能の詳細については、各クライアントのドキュメントを参考にしてください。

注意: 例のバックスラッシュ\は見やすさのために記載しており、設定フラグは 1 行で定義できます。

Besu の実行

この例では、メインネットで Besu を起動し、ブロックチェーンデータをデフォルトフォーマットで/data/ethereumに保存し、コンセンサスクライアントへの接続のために JSON RPC と Engine RPC を有効にしています。 Engine API は、トークンjwtsecretで認証され、localhostからのみ呼び出しが許可されます。

1besu --network=mainnet \
2 --data-path=/data/ethereum \
3 --rpc-http-enabled=true \
4 --engine-rpc-enabled=true \
5 --engine-host-allowlist="*" \
6 --engine-jwt-enabled=true \
7 --engine-jwt-secret=/path/to/jwtsecret
8

Besu には、一連の質問に答えることで設定ファイルを生成できるランチャーオプションもあります。 対話型ランチャーを実行するには、以下の通りです。

1besu --Xlauncher
2

Besu のドキュメントで、追加のオプションと設定の詳細を参照してください。

Erigon の実行

この例では、Erigon をメインネットで起動、ブロックチェーンデータを/data/ethereumに保存、JSON RPC を有効化、許可するネームスペースを定義、またjwtsecretパスで定義されるコンセンサスクライアントへの接続認証を有効にしています。

1erigon --chain mainnet \
2 --datadir /data/ethereum \
3 --http --http.api=engine,eth,web3,net \
4 --authrpc.jwtsecret=/path/to/jwtsecret
5

Erigon はデフォルトで 8GB の HDD でフル同期を行い、アーカイブデータは 2TB 以上となります。 datadirが十分な空き容量のあるディスクを指していることを確認するか、さまざまな種類のデータを削除する--pruneフラグを検討してください。 詳細については、Erigon の--helpオプションを参照してください。

Geth の実行

この例では、Geth をメインネットで起動、ブロックチェーンデータを/data/ethereumに保存、JSON RPC を有効化、許可するネームスペースを定義しています。 また、コンセンサスクライアントに接続するための認証を有効化し、認証に必要なjwtsecretを定義し、許可する接続のオプションも合わせて(この例ではlocalhostからのみ)定義しています。

1geth --mainnet \
2 --datadir "/data/ethereum" \
3 --http --http.api="eth,web3,net" \
4 --authrpc.vhosts="localhost" \
5 --authrpc.jwtsecret=/path/to/jwtsecret
6

すべての設定オプションのドキュメントコンセンサスクライアントと Geth を実行する方法を参照してください。

Nethermind の実行

Nethermind は、様々なインストールオプションを提供しています。 ガイド付きセットアップ機能を備えたランチャーを含むさまざまなバイナリがパッケージに含まれており、インタラクティブに設定できます。 あるいは、実行ファイルそのものであるランナーもあり、設定フラグを付けて実行することもできます。 JSON RPC はデフォルトで有効になっています。

1Nethermind.Runner --config mainnet \
2 --datadir /data/ethereum \
3 --JsonRpc.JwtSecretFile=/path/to/jwtsecret
4

Nethermind は、Nethermind とコンセンサスクライアントを実行するための完全ガイドを提供しています。

実行クライアントはコア機能と選択されたエンドポイントを開始し、ピアを探し始めます。 ピアが正常に見つかった後、クライアントは同期を開始します。 実行クライアントは、コンセンサスクライアントからの接続を待機します。 クライアントが正常に現在の状態に同期されると、現在のブロックチェーンデータが利用可能になります。

コンセンサスクライアントの開始

実行クライアントへのローカル RPC 接続を確立させために、コンセンサスクライアントを正しいポート設定で起動する必要があります。 コンセンサスクライアントは、公開した実行クライアントのポートを引数に設定して実行する必要があります。

コンセンサスクライアントは、RPC 接続を認証するために実行クライアントのjwt-secretへのパスも必要です。 上記の実行例と同様に、各コンセンサスクライアントは、jwt トークンファイルパスを引数とする設定フラグを持っています。 これは実行クライアントに使われるjwtsecretのパスと一致しなければなりません。

バリデータを運用する予定がある場合は、フィーを受け取るイーサリアムアドレスを指定する設定フラグを必ず追加してください。 これはバリデータのイーサ報酬が蓄積されるアドレスになります。 各コンセンサスクライアントは、例えば--suggested-fee-recipient=0xabcd1のように、イーサリアムアドレスを引数に取るオプションがあります。

テストネットでビーコンノードを起動する場合、チェックポイント同期にパブリックエンドポイントを使用すると、同期時間が大幅に短縮されます。

コンセンサスクライアントの実行

Lighthouse の実行

Lighthouse を実行する前に、Lighthouse Bookでインストールと設定方法の詳細を参照してください。

1lighthouse beacon_node
2 --network mainnet \
3 --datadir /data/ethereum \
4 --http \
5 --execution-endpoint http://127.0.0.1:8551 \
6 --execution-jwt /path/to/jwtsecret \
7
Lodestar の実行

Lodestar ソフトウェアをコンパイルするか、Docker イメージをダウンロードしてインストールしてください。 詳細については、ドキュメント、およびより包括的なセットアップガイドを参照してください。

1lodestar beacon \
2 --rootDir="/data/ethereum" \
3 --network=mainnet \
4 --eth1.enabled=true \
5 --execution.urls="http://127.0.0.1:8551" \
6 --jwt-secret="/path/to/jwtsecret"
7
Nimbus の実行

Nimbus には、コンセンサスクライアントと実行クライアントの両方が含まれています。 Nimbus は計算能力の低いデバイスでも実行できます。 必要なものと Nimbus 自体のインストール後、コンセンサスクライアントを実行できます。

1nimbus_beacon_node \
2 --network=mainnet \
3 --web3-url=http://127.0.0.1:8551 \
4 --rest \
5 --jwt-secret="/path/to/jwtsecret"
6
Prysm の実行

Prysm には、簡単に自動インストールできるスクリプトがあります。 詳細については、Prysm ドキュメントを参照してください。

1./prysm.sh beacon-chain \
2 --mainnet
3 --datadir /data/ethereum \
4 --execution-endpoint=http://localhost:8551 \
5 --jwt-secret=/path/to/jwtsecret
6
Teku の実行
1teku --network mainnet \
2 --data-path "/data/ethereum" \
3 --ee-endpoint http://localhost:8551 \
4 --ee-jwt-secret-file "/path/to/jwtsecret" \
5

コンセンサスクライアントが実行クライアントに接続し、デポジットコントラクトを読み込みバリデータを識別します。また、他のビーコンノードのピアにも接続し、ジェネシスブロック(最初のブロック)からコンセンサススロットの同期を開始します。 ビーコンノードが現在のエポックに達すると、ビーコン API がバリデータで使用できるようになります。 詳細については、ビーコンノード APIを参照してください。

バリデータの追加

コンセンサスクライアントは、バリデータが接続するビーコンノードとして機能します。 各コンセンサスクライアントは、それぞれのバリデータ・ソフトウェアを搭載しています。詳細については、各ドキュメントに記載されています。

自分でバリデータを実行すると、ソロステーキングができます。これはイーサリアムネットワークをサポートする上で、最も影響があり、トラストレスな方法です。 しかし、これには 32 ETH のデポジットが必要になります。 より少ない金額で自分のノードでバリデータを実行するには、Rocket Poolなど、パーミッションレスなノードオペレータの分散型プールに関心を持つかもしれません。

ステーキングとバリデータのキー生成の最も簡単な方法は、Goerli テストネット・ステーキングランチパッドを使うことです。これにより、Goerli でノードを実行し、自分のセットアップをテストすることができます。 メインネットへの準備ができたら、今度はメインネット・ステーキングランチパッドを使って、同じ手順を繰り返します。

ステーキングオプションの概要については、ステーキングページをご覧ください。

ノードの使用

実行クライアントは、トランザクションの送信、イーサリアムネットワーク上のスマートコントラクトとの対話やデプロイなど、様々な用途で使用可能なRPC API エンドポイントを提供します。

  • 適切なプロトコルで手動呼び出し(例: curl)
  • 指定したコンソールの接続(例: geth attach)
  • Web3 ライブラリを用いたアプリケーションへの実装(例: web3.pyethers)

クライアントが異なれば、RPC エンドポイントの実装も異なります。 しかし、すべてのクライアントで使用できる標準的な JSON-RPC があります。 概要については、JSON-RPC ドキュメントを参照してください。 イーサリアムネットワークからの情報を必要とするアプリケーションは、この RPC を使用できます。 例えば、人気のウォレットである MetaMask では、自分自身の RPC エンドポイントに接続することができ、プライバシーとセキュリティに大きな利点があります。

コンセンサスクライアントは、すべてBeacon APIを公開しており、これを利用してコンセンサスクライアントの状態を確認したり、Curlなどのツールを使ってリクエストを送り、ブロックやコンセンサスデータをダウンロードすることができます。 これに関する詳細については、各コンセンサスクライアントのドキュメントを参照してください。

RPC への接続

実行クライアントの JSON-RPC デフォルトポートは8545ですが、設定でローカルエンドポイントのポート番号を変更できます。 デフォルトでは、RPC インターフェイスはコンピュータのローカルホストからのみアクセス可能です。 リモートからアクセスできるようにするには、アドレスを0.0.0.0に変更し、パブリックに公開することができます。 これにより、ローカルネットワークおよびパブリック IP アドレスで接続可能になります。 ほとんどの場合、ルーターでポート転送も設定する必要があります。

インターネットにポートを公開するアプローチは、インターネット上の誰でもノードをコントロールできるようになるため、注意が必要です。 悪意のある者がノードにアクセスしてシステムをダウンさせたり、クライアントをウォレットとして使用している場合は、資金が盗まれる可能性があります。

これを回避するには、危険性のある RPC メソッドを変更できないようにすることです。 例えば、Geth の場合、フラグで変更可能なメソッドを明示することができます。--http.api web3,eth,txpool.

RPC インターフェイスへのアクセスは、エッジレイヤー API の開発、もしくは Nginx のようなウェブサーバアプリケーションからクライアントのローカルアドレスやポートに接続することで拡張できます。 デベロッパーは、ミドルレイヤーを活用することで、RPC インターフェースへセキュアなhttps接続用の証明書を設定することもできます。

ノードの RPC エンドポイントへのアクセスを付与する方法は、ウェブサーバ、プロキシ、または外向けの REST API の設定だけではありません。 別の方法として、独自のTorオニオンサービス上でノードをホストすると、プライバシーを保護しつつ、パブリックからアクセス可能なエンドポイントを設定することができます。 これにより、静的なパブリック IP アドレスやオープンポートを使用せずに、ローカルネットワーク外から RPC に到達できます。 ただし、Tor ネットワークはすべてのアプリケーションでサポートされているわけではなく、接続問題が発生する可能性があるネットワーク経由からのみ、RPC エンドポイントがアクセス可能になることに注意してください。

これを行うには、自身のオニオンサービスを作成する必要があります。 自分自身のオニオンサービスをセットアップするには、ドキュメントを参照してください。 RPC ポートへのプロキシを使って Web サーバを指すか、直接 RPC を指すことができます。

最後に、最も一般的な VPN を使って、内部ネットワークへのアクセスを提供することもできます。 ユースケースとノードへアクセスが必要なユーザーの人数にもよりますが、安全な VPN 接続は選択肢の一つとなります。 OpenVPNは、フル機能の SSL VPN です。OSI レイヤー 2 やレイヤー 3 の安全なネットワーク拡張機能を実装し、業界標準の SSL/TLS プロトコルを使います。また、証明書ベースの柔軟なクライアント認証方法もサポートしており、スマートカード認証またはユーザ名/パスワード認証の組み合わせも可能で、ユーザーやグループ固有のアクセスコントロールポリシーをファイヤーウォールルールを使い VPN の仮想インターフェースに適用できます。

ノードの運用

ノードが正常に動作するように、定期的に監視する必要があります。 時折メンテナンスが必要になる場合があります。

ノードのオンライン状態の維持

ノードが常時オンラインになっている必要はありませんが、ネットワークと同期させるためにできるだけオンラインにしておく必要があります。 シャットダウンして再起動することもできますが、以下の点に留意してください。

  • 最新の状態をディスクに書き込みれ中の場合は、シャットダウンには数分程度かかることがある。
  • 強制シャットダウンを行うと、データベースに損傷を与え、ノード全体の再同期が必要になることがある。
  • クライアントはネットワークとの同期が解除され、再起動時に再同期が必要。 ノードは最後にシャットダウンされたところから同期を開始できるが、オフラインになっていた時間に応じて処理時間が増加。

これはコンセンサスレイヤーのバリデータノードには適用されません。ノードをオフラインにすると、ノードに依存するすべてのサービスに影響を及ぼします。 ステーキング目的でノードを実行している場合は、可能な限りダウンタイムを最小限に抑えるようにしてください。

クライアントサービスの作成

起動時にクライアントを自動起動するサービスを作成することを検討してください。 例えば、Linux サーバではsystemdなどでサービスを作成し、権限が制限されたユーザーの下で、適切な設定でクライアントを実行し、自動的に再起動するように作成するのが最善の方法でしょう。

クライアントの更新

クライアントソフトウェアを最新のセキュリティパッチ、機能、 EIPで、最新の状態に保つ必要があります。 特に、ハードフォークの前に、正しいクライアントバージョンを実行していることを確認してください。

重要なネットワーク更新の前には、イーサリアム・ファウンデーション(EF)のブログで投稿されます。 これらのお知らせを購読することで、ノードの更新が必要なときにメールで通知を受け取ることができます。

クライアントの更新は非常に簡単です。 各クライアントのドキュメントに具体的な手順が記載されていますが、一般的には最新版をダウンロードし、新しい実行ファイルを使ってクライアントを再起動するだけです。 アップデートが適用され、クライアントは前回終了したところから再開するはずです。

各クライアントは、ピアツーピアプロトコルで使用される人間が判読できるバージョン文字列を持っていますが、コマンドラインからもアクセスできます。 このバージョン文字列を使って、ユーザーは自分が正しいバージョンを実行していることを確認でき、ブロックエクスプローラーやその他の分析ツールは、ネットワーク上で特定のクライアントの分散を定量化します。 バージョン文字列の詳細については、個々のクライアントのドキュメントを参照してください。

その他のサービスの実行

自分でノードを実行すると、イーサリアムクライアント RPC に直接アクセスを必要とするサービスを利用できます。 これらはレイヤー 2 ソリューション、ウォレットのバックエンド、ブロックエクスプローラー、デベロッパーツール、その他のイーサリアムインフラストラクチャのようなイーサリアム上に構築されたサービスです。

ノードの監視

ノードを適切に監視するために、メトリクスの収集を検討してください。 クライアントが提供するメトリクス・エンドポイントから、ノードに関する包括的なデータを取得できます。 InfluxDBPrometheus のようなツールを使用して、データベースを作成でき、Grafanaのようなソフトウェアで視覚化やグラフ化ができます。 このソフトウェアを使用するための多くのセットアップと、ノードとネットワーク全体を視覚化するためのさまざまな Grafana ダッシュボードがあります。 一例として、Geth の監視に関するグチュートリアルを参照してください。

モニタリングの一環として、必ずマシンのパフォーマンスを監視してください。 ノードの初期の同期中、クライアントソフトウェアは CPU と RAM に非常に大きな負荷がかかる場合があります。 Grafana に加えて、OS が提供するhtopuptimeなどのツールを使用して監視を行うこともできます。

参考文献

この記事は役に立ちましたか?