---
title: "ノードとクライアント"
description: "イーサリアムのノードとクライアントソフトウェアの概要、ノードのセットアップ方法、およびノードを実行する理由について。"
lang: ja
sidebarDepth: 2
---

[イーサリアム](/)は、ブロックとトランザクションデータを検証できるソフトウェアを実行するコンピュータ（ノードとして知られる）の分散型ネットワークです。コンピュータをイーサリアムのノードにするには、そのコンピュータ上でソフトウェアを実行する必要があります。ノードを形成するには、「クライアント」と呼ばれる2つの別々のソフトウェアが必要です。

## 前提条件 {#prerequisites}

イーサリアムクライアントの独自のインスタンスを実行して深く掘り下げる前に、ピア・ツー・ピアネットワークの概念と[EVMの基礎](/developers/docs/evm/)を理解しておく必要があります。[イーサリアムの紹介](/developers/docs/intro-to-ethereum/)をご覧ください。

ノードのトピックが初めての場合は、まず[イーサリアムノードの実行](/run-a-node)に関するユーザーフレンドリーな紹介を確認することをお勧めします。

## ノードとクライアントとは？ {#what-are-nodes-and-clients}

「ノード」とは、イーサリアムソフトウェアを実行している他のコンピュータに接続され、ネットワークを形成しているイーサリアムクライアントソフトウェアのインスタンスのことです。クライアントは、プロトコルのルールに照らしてデータを検証し、ネットワークを安全に保つイーサリアムの実装です。ノードは、コンセンサス・クライアントと実行クライアントの2つのクライアントを実行する必要があります。

- 実行クライアント（実行エンジン、ELクライアント、または以前のEth1クライアントとも呼ばれます）は、ネットワークでブロードキャストされた新しいトランザクションをリッスンし、EVMで実行し、最新の状態と現在のすべてのイーサリアムデータのデータベースを保持します。
- コンセンサス・クライアント（ビーコン・ノード、CLクライアント、または以前のEth2クライアントとも呼ばれます）は、プルーフ・オブ・ステーク (PoS) コンセンサスアルゴリズムを実装しており、実行クライアントからの検証済みデータに基づいてネットワークが合意に達することを可能にします。また、コンセンサス・クライアントに追加できる「バリデータ」と呼ばれる3つ目のソフトウェアもあり、これによりノードはネットワークの保護に参加できます。

これらのクライアントは連携してイーサリアムチェーンの先頭を追跡し、ユーザーがイーサリアムネットワークと対話できるようにします。複数のソフトウェアが連携して機能するモジュール設計は、[カプセル化された複雑さ](https://vitalik.eth.limo/general/2022/02/28/complexity.html)と呼ばれます。このアプローチにより、[マージ](/roadmap/merge)をシームレスに実行しやすくなり、クライアントソフトウェアの保守と開発が容易になり、たとえば[レイヤー2 (L2) エコシステム](/layer-2/)などで個々のクライアントを再利用できるようになります。

![Coupled execution and consensus clients](./eth1eth2client.png)
結合された実行クライアントとコンセンサス・クライアントの簡略図。

### クライアント・ダイバーシティ {#client-diversity}

[実行クライアント](/developers/docs/nodes-and-clients/#execution-clients)と[コンセンサス・クライアント](/developers/docs/nodes-and-clients/#consensus-clients)はどちらも、さまざまなチームによって開発された多様なプログラミング言語で存在します。

複数のクライアント実装により、単一のコードベースへの依存を減らすことで、ネットワークをより強固にすることができます。理想的な目標は、どのクライアントもネットワークを支配することなく多様性を実現し、潜在的な単一障害点を排除することです。
言語の多様性は、より幅広い開発者コミュニティを招き入れ、彼らが好みの言語で統合を作成できるようにします。

[クライアント・ダイバーシティ](/developers/docs/nodes-and-clients/client-diversity/)についてさらに学ぶ。

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

- 当初は、[イーサリアムのイエロー・ペーパー](https://ethereum.github.io/yellowpaper/paper.pdf)
- [実行仕様](https://github.com/ethereum/execution-specs/)
- [コンセンサス仕様](https://github.com/ethereum/consensus-specs)
- さまざまな[ネットワークアップグレード](/ethereum-forks/)で実装された[EIP](https://eips.ethereum.org/)

### ネットワーク内のノードの追跡 {#network-overview}

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

- Etherscanによる[ノードのマップ](https://etherscan.io/nodetracker)
- Bitflyによる[Ethernodes](https://ethernodes.org/)
- Chainsafeによる[Nodewatch](https://www.nodewatch.io/)（コンセンサスノードをクロール）
- MigaLabsによる[Monitoreth](https://monitoreth.io/) - 分散型ネットワーク監視ツール
- ProbeLabによる[週次ネットワーク健全性レポート](https://probelab.io) - [Nebulaクローラー](https://github.com/dennis-tra/nebula)やその他のツールを使用

## ノードの種類 {#node-types}

[独自のノードを実行](/developers/docs/nodes-and-clients/run-a-node/)したい場合は、データの消費方法が異なるさまざまな種類のノードがあることを理解しておく必要があります。実際、クライアントはライト、フル、アーカイブの3種類のノードを実行できます。また、同期時間を短縮できるさまざまな同期ストラテジーのオプションもあります。同期とは、イーサリアムの状態に関する最新情報をどれだけ早く取得できるかを指します。

### フル・ノード {#full-node}

フル・ノードは、各ブロックのブロック本体と状態データのダウンロードと検証を含め、ブロックチェーンのブロックごとの検証を行います。フル・ノードにはさまざまなクラスがあります。ジェネシス・ブロックから開始し、ブロックチェーンの全履歴にあるすべてのブロックを検証するものもあります。他のものは、有効であると信頼するより最近のブロックから検証を開始します（例：ゴー・イーサリアム（ゲス）の「スナップ同期」）。検証がどこから始まるかに関係なく、フル・ノードは比較的最近のデータ（通常は最新の128ブロック）のローカルコピーのみを保持し、古いデータを削除してディスク容量を節約できるようにします。古いデータは、必要になったときに再生成できます。

- 完全なブロックチェーンデータを保存します（ただし、これは定期的にプルーニングされるため、フル・ノードはジェネシスまでのすべての状態データを保存するわけではありません）。
- ブロック検証に参加し、すべてのブロックと状態を検証します。
- すべての状態は、ローカルストレージから取得するか、フル・ノードによって「スナップショット」から再生成できます。
- ネットワークにサービスを提供し、要求に応じてデータを提供します。

### アーカイブ・ノード {#archive-node}

アーカイブ・ノードは、ジェネシスからのすべてのブロックを検証し、ダウンロードしたデータを一切削除しないフル・ノードです。

- フル・ノードに保持されているすべてのものを保存し、過去の状態のアーカイブを構築します。ブロック番号4,000,000でのアカウント残高などをクエリしたい場合や、トレースを使用して検証することなく、独自のトランザクションセットを簡単かつ確実にテストしたい場合に必要です。
- このデータはテラバイト単位になるため、一般ユーザーにとってアーカイブ・ノードの魅力は低くなりますが、ブロックエクスプローラー、ウォレットベンダー、チェーン分析などのサービスには便利です。

アーカイブ以外のモードでクライアントを同期すると、ブロックチェーンデータがプルーニングされます。つまり、すべての過去の状態のアーカイブはありませんが、フル・ノードはオンデマンドでそれらを構築できます。

[アーカイブ・ノード](/developers/docs/nodes-and-clients/archive-nodes)についてさらに学ぶ。

### ライト・ノード {#light-node}

すべてのブロックをダウンロードする代わりに、ライト・ノードはブロックヘッダーのみをダウンロードします。これらのヘッダーには、ブロックの内容に関する要約情報が含まれています。ライト・ノードが必要とするその他の情報は、フル・ノードに要求されます。その後、ライト・ノードは、受信したデータをブロックヘッダー内の状態ルートと照らし合わせて独自に検証できます。ライト・ノードを使用すると、ユーザーはフル・ノードの実行に必要な強力なハードウェアや高帯域幅がなくても、イーサリアムネットワークに参加できます。最終的には、ライト・ノードは携帯電話や組み込みデバイスで実行されるようになるかもしれません。ライト・ノードはコンセンサスに参加しません（つまり、バリデータにはなれません）が、フル・ノードと同じ機能とセキュリティ保証でイーサリアムブロックチェーンにアクセスできます。

ライト・クライアントはイーサリアムの活発な開発分野であり、コンセンサス・レイヤーと実行レイヤー向けの新しいライト・クライアントが間もなく登場すると予想しています。
また、[ゴシップネットワーク](https://www.ethportal.net/)を介してライト・クライアントデータを提供する潜在的なルートもあります。これは、ゴシップネットワークが、フル・ノードにリクエストを処理させることなく、ライト・ノードのネットワークをサポートできるため有利です。

イーサリアムはまだ多数のライト・ノードをサポートしていませんが、ライト・ノードのサポートは近い将来急速に発展すると予想される分野です。特に、[ニンバス](https://nimbus.team/)、[Helios](https://github.com/a16z/helios)、[ロードスター](https://lodestar.chainsafe.io/)などのクライアントは、現在ライト・ノードに重点を置いています。

## なぜイーサリアムノードを実行する必要があるのですか？ {#why-should-i-run-an-ethereum-node}

ノードを実行すると、イーサリアムを直接、トラストレスかつプライベートに使用できると同時に、ネットワークをより堅牢で分散化された状態に保つことでネットワークをサポートできます。

### あなたにとってのメリット {#benefits-to-you}

独自のノードを実行すると、プライベートで自給自足のトラストレスな方法でイーサリアムを使用できます。クライアントを使用して自分でデータを検証できるため、ネットワークを信頼する必要はありません。「信頼するな、検証せよ」は、ブロックチェーンの有名なマントラです。

- あなたのノードは、コンセンサス・ルールに照らしてすべてのトランザクションとブロックを独自に検証します。つまり、ネットワーク内の他のノードに依存したり、それらを完全に信頼したりする必要はありません。
- 独自のノードでイーサリアムウォレットを使用できます。アドレスや残高を仲介者に漏らす必要がないため、分散型アプリケーション (dapp) をより安全かつプライベートに使用できます。すべては独自のクライアントで確認できます。[メタマスク](https://metamask.io)、[Frame](https://frame.sh/)、および[他の多くのウォレット](/wallets/find-wallet/)はRPCインポートを提供しており、あなたのノードを使用できます。
- イーサリアムからのデータに依存する他のサービスを実行およびセルフホストできます。たとえば、ビーコン・チェーンのバリデータ、レイヤー2 (L2) のようなソフトウェア、インフラストラクチャ、ブロックエクスプローラー、決済プロセッサなどです。
- 独自のカスタム[RPCエンドポイント](/developers/docs/apis/json-rpc/)を提供できます。これらのエンドポイントをコミュニティに公開して、大規模な中央集権型プロバイダーを回避するのを支援することもできます。
- **プロセス間通信 (IPC)** を使用してノードに接続したり、プログラムをプラグインとしてロードするようにノードを書き換えたりできます。これにより低遅延が実現し、Web3ライブラリを使用して大量のデータを処理する場合や、トランザクションをできるだけ早く置き換える必要がある場合（フロントランニングなど）に非常に役立ちます。
- ETHを直接ステークしてネットワークを保護し、報酬を獲得できます。開始するには、[ソロ・ステーキング](/staking/solo/)を参照してください。

![How you access Ethereum via your application and nodes](./nodes.png)

### ネットワークのメリット {#network-benefits}

多様なノードのセットは、イーサリアムの健全性、セキュリティ、および運用上の回復力にとって重要です。

- フル・ノードはコンセンサス・ルールを適用するため、ルールに従わないブロックを受け入れるように騙されることはありません。すべてのノードが完全な検証を行わないライト・ノードであった場合、バリデータがネットワークを攻撃する可能性があるため、これによりネットワークにさらなるセキュリティが提供されます。
- [プルーフ・オブ・ステーク (PoS)](/developers/docs/consensus-mechanisms/pos/#what-is-pos)の暗号経済的防御を打ち破る攻撃が発生した場合、フル・ノードが正直なチェーンに従うことを選択することで、ソーシャル・リカバリーを実行できます。
- ネットワーク内のノードが増えると、ネットワークがより多様で堅牢になります。これは分散化の究極の目標であり、検閲耐性のある信頼性の高いシステムを可能にします。
- フル・ノードは、ブロックチェーンデータに依存する軽量クライアントにアクセスを提供します。ライト・ノードはブロックチェーン全体を保存せず、代わりに[ブロックヘッダー内の状態ルート](/developers/docs/blocks/#block-anatomy)を介してデータを検証します。必要に応じて、フル・ノードに詳細情報を要求できます。

フル・ノードを実行すると、バリデータを実行していなくても、イーサリアムネットワーク全体がその恩恵を受けます。

## 独自のノードの実行 {#running-your-own-node}

独自のイーサリアムクライアントを実行することに興味がありますか？

初心者向けの紹介については、[ノードの実行](/run-a-node)ページにアクセスして詳細をご覧ください。

より技術的なユーザーの場合は、[独自のノードを立ち上げる](/developers/docs/nodes-and-clients/run-a-node/)方法に関する詳細とオプションを掘り下げてください。

## 代替手段 {#alternatives}

独自のノードをセットアップするには時間とリソースがかかる場合がありますが、常に独自のインスタンスを実行する必要はありません。この場合、サードパーティのAPIプロバイダーを使用できます。これらのサービスの使用の概要については、[サービスとしてのノード](/developers/docs/nodes-and-clients/nodes-as-a-service/)を確認してください。

コミュニティの誰かがパブリックAPIを備えたイーサリアムノードを実行している場合、カスタムRPCを介してウォレットをコミュニティノードに向けることができ、ランダムな信頼できるサードパーティよりも高いプライバシーを得ることができます。

一方、クライアントを実行している場合は、それを必要としているかもしれない友人と共有することができます。

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

イーサリアムコミュニティは、さまざまなプログラミング言語を使用してさまざまなチームによって開発された、複数のオープンソースの実行クライアント（以前は「Eth1クライアント」、または単に「イーサリアムクライアント」と呼ばれていました）を維持しています。これにより、ネットワークはより強固になり、より[多様](/developers/docs/nodes-and-clients/client-diversity/)になります。理想的な目標は、単一障害点を減らすために、どのクライアントも支配することなく多様性を実現することです。

この表は、さまざまなクライアントをまとめたものです。これらはすべて[クライアントテスト](https://github.com/ethereum/tests)に合格しており、ネットワークのアップグレードに合わせて最新の状態を保つために積極的に保守されています。

| クライアント | 言語 | オペレーティングシステム | ネットワーク | 同期ストラテジー | 状態のプルーニング |
| --- | --- | --- | --- | --- | --- |
| [ゴー・イーサリアム（ゲス）](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | メインネット, Sepolia, Hoodi | [スナップ](#snap-sync), [フル](#full-sync) | アーカイブ, プルーニング済み |
| [ネザーマインド](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | メインネット, Sepolia, Hoodi | [スナップ](#snap-sync), 高速, [フル](#full-sync) | アーカイブ, プルーニング済み |
| [ベス](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | メインネット, Sepolia, Hoodi | [スナップ](#snap-sync), [高速](#fast-sync), [フル](#full-sync) | アーカイブ, プルーニング済み |
| [エリゴン](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | メインネット, Sepolia, Hoodi | [フル](#full-sync) | アーカイブ, プルーニング済み |
| [レス](https://reth.rs/) | Rust | Linux, Windows, macOS | メインネット, Sepolia, Hoodi | [フル](#full-sync) | アーカイブ, プルーニング済み |
| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(ベータ版)_ | TypeScript | Linux, Windows, macOS | Sepolia, Hoodi | [フル](#full-sync) | プルーニング済み |

サポートされているネットワークの詳細については、[イーサリアムネットワーク](/developers/docs/networks/)をお読みください。

各クライアントには独自のユースケースと利点があるため、自分の好みに基づいて選択する必要があります。多様性により、実装はさまざまな機能やユーザー層に焦点を当てることができます。機能、サポート、プログラミング言語、またはライセンスに基づいてクライアントを選択することをお勧めします。

### ベス {#besu}

Hyperledger ベスは、パブリックおよびパーミッションドネットワーク向けのエンタープライズグレードのイーサリアムクライアントです。トレースからGraphQLまで、イーサリアム・メインネットのすべての機能を実行し、広範な監視機能を備えており、オープンなコミュニティチャネルと企業向けの商用SLAの両方を通じてコンセンシスによってサポートされています。Javaで記述されており、Apache 2.0ライセンスです。

ベスの広範な[ドキュメント](https://besu.hyperledger.org/en/stable/)では、その機能とセットアップに関するすべての詳細を案内しています。

### エリゴン {#erigon}

エリゴン（旧称Turbo-Geth）は、速度とディスク容量の効率化を指向したゴー・イーサリアム（ゲス）のフォークとして始まりました。エリゴンは完全に再設計されたイーサリアムの実装であり、現在はGoで記述されていますが、他の言語での実装も開発中です。エリゴンの目標は、より高速で、よりモジュール化され、より最適化されたイーサリアムの実装を提供することです。約2TBのディスク容量を使用して、3日未満で完全なアーカイブ・ノードの同期を実行できます。


ethrexは、Rustで記述され、LambdaClassによって開発された、ミニマリストでモジュール式のイーサリアム実行クライアントです。ゼロ知識証明を念頭に置いて構築されており、同じコードベースをL1実行クライアントとしても、マルチプルーバーのZKロールアップ (L2) としても実行できます。Apache 2.0およびMITライセンスの下でデュアルライセンスされています。

詳細については、[ethrexのドキュメント](https://docs.ethrex.xyz/)を読むか、[ethrexのGitHubリポジトリ](https://github.com/lambdaclass/ethrex)を確認してください。
### ゴー・イーサリアム（ゲス） {#geth}

ゴー・イーサリアム（ゲス）（略してGeth）は、イーサリアムプロトコルのオリジナル実装の1つです。現在、最大のユーザーベースと、ユーザーおよび開発者向けのさまざまなツールを備えた、最も普及しているクライアントです。Goで記述されており、完全にオープンソースで、GNU LGPL v3の下でライセンスされています。

Gethの詳細については、その[ドキュメント](https://geth.ethereum.org/docs)をご覧ください。

### ネザーマインド {#nethermind}

ネザーマインドは、C# .NET技術スタックで作成されたイーサリアム実装であり、LGPL-3.0でライセンスされ、ARMを含むすべての主要なプラットフォームで実行されます。以下により優れたパフォーマンスを提供します。

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

ネザーマインドには、[詳細なドキュメント](https://docs.nethermind.io)、強力な開発者サポート、オンラインコミュニティもあり、プレミアムユーザーは24時間年中無休のサポートを利用できます。

### レス {#reth}

レス（Rust Ethereumの略）は、ユーザーフレンドリーで、高度にモジュール化され、高速かつ効率的であることに重点を置いたイーサリアムのフル・ノード実装です。レスは元々Paradigmによって構築および推進され、ApacheおよびMITライセンスの下でライセンスされています。

レスは本番環境に対応しており、ステーキングや高稼働率サービスなどのミッションクリティカルな環境での使用に適しています。RPC、MEV、インデックス作成、シミュレーション、P2Pアクティビティなど、大きなマージンを伴う高いパフォーマンスが要求されるユースケースで優れたパフォーマンスを発揮します。

詳細については、[Reth Book](https://reth.rs/)、または[RethのGitHubリポジトリ](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth)を確認してください。

### 開発中 {#execution-in-development}

これらのクライアントはまだ開発の初期段階にあり、本番環境での使用はまだ推奨されていません。

#### EthereumJS {#ethereumjs}

EthereumJS実行クライアント (EthereumJS) はTypeScriptで記述されており、ブロック、トランザクション、マークルパトリシアトライクラスで表されるコアなイーサリアムプリミティブや、イーサリアム仮想マシン (EVM) の実装、ブロックチェーンクラス、devp2pネットワーキングスタックなどのコアクライアントコンポーネントを含む、多数のパッケージで構成されています。

詳細については、その[ドキュメント](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master)をお読みください。

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

[コンセンサスのアップグレード](/roadmap/beacon-chain/)をサポートするために、複数のコンセンサス・クライアント（以前は「Eth2」クライアントと呼ばれていました）があります。これらは、フォーク選択アルゴリズム、アテステーションの処理、[プルーフ・オブ・ステーク (PoS)](/developers/docs/consensus-mechanisms/pos)の報酬とペナルティの管理など、コンセンサスに関連するすべてのロジックを担当します。

| クライアント | 言語 | オペレーティングシステム | ネットワーク |
| --- | --- | --- | --- |
| [ライトハウス](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | ビーコン・チェーン, Hoodi, Pyrmont, Sepolia, その他 |
| [ロードスター](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | ビーコン・チェーン, Hoodi, Sepolia, その他 |
| [ニンバス](https://nimbus.team/) | Nim | Linux, Windows, macOS | ビーコン・チェーン, Hoodi, Sepolia, その他 |
| [プリズム](https://prysm.offchainlabs.com/docs/) | Go | Linux, Windows, macOS | ビーコン・チェーン, Gnosis, Hoodi, Pyrmont, Sepolia, その他 |
| [テク](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | ビーコン・チェーン, Gnosis, Hoodi, Sepolia, その他 |
| [Grandine](https://docs.grandine.io/) | Rust | Linux, Windows, macOS | ビーコン・チェーン, Hoodi, Sepolia, その他 |

### ライトハウス {#lighthouse}

ライトハウスは、Apache-2.0ライセンスの下でRustで記述されたコンセンサス・クライアントの実装です。Sigma Primeによって保守されており、ビーコン・チェーンのジェネシス以来、安定しており本番環境に対応しています。さまざまな企業、ステーキングプール、個人から信頼されています。デスクトップPCから高度な自動デプロイメントまで、幅広い環境で安全でパフォーマンスが高く、相互運用可能であることを目指しています。

ドキュメントは[Lighthouse Book](https://lighthouse-book.sigmaprime.io/)にあります。

### ロードスター {#lodestar}

ロードスターは、LGPL-3.0ライセンスの下でTypeScriptで記述された、本番環境に対応したコンセンサス・クライアントの実装です。ChainSafe Systemsによって保守されており、ソロ・ステーキングを行う人、開発者、研究者向けのコンセンサス・クライアントの中で最も新しいものです。ロードスターは、イーサリアムプロトコルのJavaScript実装を利用したビーコン・ノードとバリデータクライアントで構成されています。ロードスターは、ライト・クライアントによるイーサリアムの使いやすさの向上、より多くの開発者グループへのアクセシビリティの拡大、およびエコシステムの多様性へのさらなる貢献を目指しています。

詳細については、[ロードスターのウェブサイト](https://lodestar.chainsafe.io/)をご覧ください。

### ニンバス {#nimbus}

ニンバスは、Apache-2.0ライセンスの下でNimで記述されたコンセンサス・クライアントの実装です。ソロ・ステーキングを行う人やステーキングプールで使用されている、本番環境に対応したクライアントです。ニンバスはリソース効率を考慮して設計されており、安定性や報酬のパフォーマンスを損なうことなく、リソースが制限されたデバイスやエンタープライズインフラストラクチャで同じように簡単に実行できます。リソースフットプリントが軽いということは、ネットワークに負荷がかかっているときにクライアントの安全マージンが大きくなることを意味します。

詳細については、[ニンバスのドキュメント](https://nimbus.guide/)をご覧ください。

### プリズム {#prysm}

プリズムは、GPL-3.0ライセンスの下でGoで記述された、フル機能のオープンソースのコンセンサス・クライアントです。オプションのWebアプリUIを備えており、自宅でステークするユーザーと機関ユーザーの両方にとって、ユーザーエクスペリエンス、ドキュメント、および構成可能性を優先しています。

詳細については、[プリズムのドキュメント](https://prysm.offchainlabs.com/docs/)をご覧ください。

### テク {#teku}

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

テクは非常に柔軟なデプロイオプションを提供します。ビーコン・ノードとバリデータクライアントは単一のプロセスとして一緒に実行でき、これはソロ・ステーキングを行う人にとって非常に便利です。また、高度なステーキング操作のためにノードを個別に実行することもできます。さらに、テクは署名鍵のセキュリティとスラッシング保護のために[Web3Signer](https://github.com/ConsenSys/web3signer/)と完全に相互運用可能です。

テクはJavaで記述されており、Apache 2.0ライセンスです。ベスとWeb3Signerも担当しているコンセンシスのプロトコルチームによって開発されています。詳細については、[テクのドキュメント](https://docs.teku.consensys.net/en/latest/)をご覧ください。

### Grandine {#grandine}

Grandineは、GPL-3.0ライセンスの下でRustで記述されたコンセンサス・クライアントの実装です。Grandineコアチームによって保守されており、高速、高性能、軽量です。Raspberry Piなどの低リソースデバイスで実行するソロ・ステーキングを行う人から、数万のバリデータを実行する大規模な機関のステーキングを行う人まで、幅広いステーキングを行う人に適しています。

ドキュメントは[Grandine Book](https://docs.grandine.io/)にあります。

## 同期モード {#sync-modes}

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

同期モードは、さまざまなトレードオフを伴うこのプロセスへの異なるアプローチを表しています。クライアントは、同期アルゴリズムの実装も異なります。実装の詳細については、常に選択したクライアントの公式ドキュメントを参照してください。

### 実行レイヤーの同期モード {#execution-layer-sync-modes}

実行レイヤーは、ブロックチェーンのワールド状態の再実行から、信頼できるチェックポイントからのチェーンの先端との同期のみまで、さまざまなユースケースに合わせてさまざまなモードで実行できます。

#### フル同期 {#full-sync}

フル同期は、すべてのブロック（ヘッダーとブロック本体を含む）をダウンロードし、ジェネシスからすべてのブロックを実行することで、ブロックチェーンの状態を段階的に再生成します。

- すべてのトランザクションを検証することで、信頼を最小限に抑え、最高のセキュリティを提供します。
- トランザクションの数が増加しているため、すべてのトランザクションを処理するのに数日から数週間かかる場合があります。

[アーカイブ・ノード](#archive-node)はフル同期を実行して、すべてのブロックのすべてのトランザクションによって行われた状態変更の完全な履歴を構築（および保持）します。

#### 高速同期 {#fast-sync}

フル同期と同様に、高速同期はすべてのブロック（ヘッダー、トランザクション、レシートを含む）をダウンロードします。ただし、過去のトランザクションを再処理する代わりに、高速同期は最近の先頭に到達するまでレシートに依存し、先頭に到達した時点でブロックのインポートと処理に切り替えてフル・ノードを提供します。

- 高速同期ストラテジー。
- 帯域幅の使用を優先して、処理の需要を減らします。

#### スナップ同期 {#snap-sync}

スナップ同期もチェーンをブロックごとに検証します。ただし、ジェネシス・ブロックから開始するのではなく、スナップ同期は、真のブロックチェーンの一部であることがわかっている、より最近の「信頼できる」チェックポイントから開始します。ノードは定期的なチェックポイントを保存しながら、一定の期間より古いデータを削除します。これらのスナップショットは、状態データを永久に保存するのではなく、必要に応じて再生成するために使用されます。

- 最速の同期ストラテジーであり、現在イーサリアム・メインネットのデフォルトです。
- セキュリティを犠牲にすることなく、ディスク使用量とネットワーク帯域幅を大幅に節約します。

[スナップ同期の詳細](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)。

#### ライト同期 {#light-sync}

ライト・クライアントモードは、すべてのブロックヘッダーとブロックデータをダウンロードし、一部をランダムに検証します。信頼できるチェックポイントからチェーンの先端のみを同期します。

- 開発者とコンセンサス・メカニズムへの信頼に依存しながら、最新の状態のみを取得します。
- クライアントは数分で現在のネットワーク状態で使用できるようになります。

**注意** ライト同期はまだプルーフ・オブ・ステーク (PoS) のイーサリアムでは機能しません。ライト同期の新しいバージョンが間もなくリリースされる予定です！

[ライト・クライアントの詳細](/developers/docs/nodes-and-clients/light-clients/)

### コンセンサス・レイヤーの同期モード {#consensus-layer-sync-modes}

#### オプティミスティック同期 {#optimistic-sync}

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

[オプティミスティック同期の詳細](https://github.com/ethereum/consensus-specs/blob/master/sync/optimistic.md)

#### チェックポイント同期 {#checkpoint-sync}

チェックポイント同期（弱い主観性同期とも呼ばれます）は、ビーコン・ノードを同期するための優れたユーザーエクスペリエンスを生み出します。これは[弱い主観性](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/)の前提に基づいており、ジェネシスではなく最近の弱い主観性のチェックポイントからビーコン・チェーンを同期できるようにします。チェックポイント同期は、[ジェネシス](/glossary/#genesis-block)からの同期と同様のトラスト前提で、初期同期時間を大幅に短縮します。

実際には、これはノードがリモートサービスに接続して最近のファイナライズ済みの状態をダウンロードし、その時点からデータの検証を継続することを意味します。データを提供するサードパーティは信頼されており、慎重に選択する必要があります。

[チェックポイント同期](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)の詳細

## 参考文献 {#further-reading}

- [Ethereum 101 - パート2 - ノードの理解](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes、2019年2月13日_
- [イーサリアムフルノードの実行：やる気のない人のためのガイド](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux、2019年11月7日_

## 関連トピック {#related-topics}

- [ブロック](/developers/docs/blocks/)
- [ネットワーク](/developers/docs/networks/)

## 関連チュートリアル {#related-tutorials}

- [MicroSDカードをフラッシュするだけでRaspberry Pi 4をバリデータノードにする – インストールガイド](/developers/tutorials/run-node-raspberry-pi/) _– Raspberry Pi 4をフラッシュし、イーサネットケーブルを接続し、SSDディスクを接続してデバイスの電源を入れると、Raspberry Pi 4が実行レイヤー（メインネット）および/またはコンセンサス・レイヤー（ビーコン・チェーン / バリデータ）を実行する完全なイーサリアムノードになります。_