description: Instructions for connecting Geth to a consensus client
---
Geth is an [execution client][ex-client-link]. Historically, an execution client alone was enough to
run a full Ethereum node. However, ever since Ethereum swapped from [proof-of-work][pow-link] (PoW) to
[proof-of-stake][pos-link] (PoS) based consensus, Geth has needed to be coupled to another piece of
software called a ["consensus client"][con-client-link].
Geth is an [execution client](https://ethereum.org/en/glossary/#execution-client). Historically, an execution client alone was enough to run a full Ethereum node. However, ever since Ethereum swapped from [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow) (PoW) to [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos) (PoS) based consensus, Geth has needed to be coupled to another piece of software called a ["consensus client"](https://ethereum.org/en/glossary/#consensus-client).
There are five consensus clients available, all of which connect to Geth in the same way.
This page will outline how Geth can be set up with a consensus client to form a complete Ethereum node.
There are five consensus clients available, all of which connect to Geth in the same way. This page will outline how Geth can be set up with a consensus client to form a complete Ethereum node.
## Configuring Geth
Geth can be downloaded and installed according to the instructions on the
[Installing Geth](/docs/install-and-build/installing-geth) page. In order to connect to a consensus client,
Geth must expose a port for the inter-client RPC connection.
Geth can be downloaded and installed according to the instructions on the [Installing Geth](/docs/install-and-build/installing-geth) page. In order to connect to a consensus client, Geth must expose a port for the inter-client RPC connection.
The RPC connection must be authenticated using a `jwtsecret` file. This is created and saved
to `<datadir>/geth/jwtsecret` by default but can also be created and saved to a custom location or it can be
self-generated and provided to Geth by passing the file path to `--authrpc.jwtsecret`. The `jwtsecret` file
is required by both Geth and the consensus client.
The RPC connection must be authenticated using a `jwtsecret` file. This is created and saved to `<datadir>/geth/jwtsecret` by default but can also be created and saved to a custom location or it can be self-generated and provided to Geth by passing the file path to `--authrpc.jwtsecret`. The `jwtsecret` file is required by both Geth and the consensus client.
The authorization must then be applied to a specific address/port. This is achievd by passing an address to
`--authrpc.addr` and a port number to `--authrpc.port`. It is also safe to provide either `localhost` or a wildcard
`*` to `--authrpc.vhosts` so that incoming requests from virtual hosts are accepted by Geth because it only
applies to the port authenticated using `jwtsecret`.
The authorization must then be applied to a specific address/port. This is achieved by passing an address to `--authrpc.addr` and a port number to `--authrpc.port`. It is also safe to provide either `localhost` or a wildcard `*` to `--authrpc.vhosts` so that incoming requests from virtual hosts are accepted by Geth because it only applies to the port authenticated using `jwtsecret`.
A complete command to start Geth so that it can connect to a consensus client looks as follows:
@ -33,7 +21,6 @@ A complete command to start Geth so that it can connect to a consensus client lo
There are currently four consensus clients that can be run alongside Geth. These are:
@ -48,36 +35,21 @@ There are currently four consensus clients that can be run alongside Geth. These
[Lodestar](https://lodestar.chainsafe.io/): written in Typescript
It is recommended to consider [client diversity][client-div-link] when choosing a consensus client.
Instructions for installing each client are provided in the documentation linked in the list above.
It is recommended to consider [client diversity](https://ethereum.org/en/developers/docs/nodes-and-clients/client-diversity) when choosing a consensus client. Instructions for installing each client are provided in the documentation linked in the list above.
The consensus client must be started with the right port configuration to establish an RPC connection
to the local Geth instance. In the example above, `localhost:8551` was authorized
for this purpose. The consensus clients all have a command similar to `--http-webprovider` that
takes the exposed Geth port as an argument.
The consensus client must be started with the right port configuration to establish an RPC connection to the local Geth instance. In the example above, `localhost:8551` was authorized for this purpose. The consensus clients all have a command similar to `--http-webprovider` that takes the exposed Geth port as an argument.
The consensus client also needs the path to Geth's `jwt-secret` in order to authenticate the RPC connection between them.
Each consensus client has a command similar to `--jwt-secret` that takes the file path as an argument. This must
be consistent with the `--authrpc.jwtsecret` path provided to Geth.
The consensus client also needs the path to Geth's `jwt-secret` in order to authenticate the RPC connection between them. Each consensus client has a command similar to `--jwt-secret` that takes the file path as an argument. This must be consistent with the `--authrpc.jwtsecret` path provided to Geth.
The consensus clients all expose a [Beacon API][beacon-api-link] that can be used to check the status
of the Beacon client or download blocks and consensus data by sending requests using tools such as
[Curl](https://curl.se). More information on this can be found in the documentation for each consensus client.
The consensus clients all expose a [Beacon API](https://ethereum.github.io/beacon-APIs) that can be used to check the status of the Beacon client or download blocks and consensus data by sending requests using tools such as [Curl](https://curl.se). More information on this can be found in the documentation for each consensus client.
## Validators
Validators are responsible for securing the Ethereum blockchain. Validators have staked at least 32 ETH into a
deposit contract and run validator software. Each of the consensus clients have their own validator software that
is described in detail in their respective documentation. The easiest way to handle staking and validator
key generation is to use the Ethereum Foundation [Staking Launchpad][launchpad-link]. The Launchpad guides users
through the process of generating validator keys and connecting the validator to the consensus client.
Validators are responsible for securing the Ethereum blockchain. Validators have staked at least 32 ETH into a deposit contract and run validator software. Each of the consensus clients have their own validator software that is described in detail in their respective documentation. The easiest way to handle staking and validator key generation is to use the Ethereum Foundation [Staking Launchpad](https://launchpad.ethereum.org/). The Launchpad guides users through the process of generating validator keys and connecting the validator to the consensus client.
## Using Geth
Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available
for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js
or HTTP requests with commands as json payloads. These options are explained in more detail on the
[Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started
Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started
using the following command in a separate terminal (assuming Geth's IPC file is saved in `datadir`):
```shell
@ -86,22 +58,6 @@ geth attach datadir/geth.ipc
## Summary
Now that Ethereum has implemented proof-of-stake, Geth users are required to install and run a consensus client.
Otherwise, Geth will not be able to track the head of the chain. There are five consensus clients to choose from.
This page provided an overview of how to choose a consensus client and configure Geth to connect to it.
Now that Ethereum has implemented proof-of-stake, Geth users are required to install and run a consensus client. Otherwise, Geth will not be able to track the head of the chain. There are five consensus clients to choose from. This page provided an overview of how to choose a consensus client and configure Geth to connect to it.
description: introduction to the devp2p peer-to-peer networking tool
---
[DevP2P](https://github.com/ethereum/devp2p) is a set of network protocols that form the
Ethereum peer-to-peer network. The DevP2P specifications define precisely how nodes
should find each other and communicate. Geth implements the DevP2P specifications in Go.
[DevP2P](https://github.com/ethereum/devp2p) is a set of network protocols that form the Ethereum peer-to-peer network. The DevP2P specifications define precisely how nodes should find each other and communicate. Geth implements the DevP2P specifications in Go.
The DevP2P stack includes the low-level peer-to-peer protocols that define discovery and
secure sessions between nodes such as:
The DevP2P stack includes the low-level peer-to-peer protocols that define discovery and secure sessions between nodes such as:
[Ethereum Node Records](https://github.com/ethereum/devp2p/blob/master/enr.md): A standard format for connectivity information for a node
[Discovery protocol](https://github.com/ethereum/devp2p/blob/master/discv4.md): Defines how nodes find each other.
[RLPx protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md): Defines a TCP based transport system for communication between nodes.
- [Ethereum Node Records](https://github.com/ethereum/devp2p/blob/master/enr.md): A standard format for connectivity information for a node
- [Discovery protocol](https://github.com/ethereum/devp2p/blob/master/discv4.md): Defines how nodes find each other.
- [RLPx protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md): Defines a TCP based transport system for communication between nodes.
DevP2P also includes the RLPx-based application level protocols including:
[Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/master/caps/eth.md): facilitates exchange of blockchain data between peers
[Ethereum Snapshot Protocol](https://github.com/ethereum/devp2p/blob/master/caps/snap.md): enables exchange of snapshots between peers
[Light Ethereum Subprotocol](https://github.com/ethereum/devp2p/blob/master/caps/les.md): protocol used by light clients
- [Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/master/caps/eth.md): facilitates exchange of blockchain data between peers
- [Ethereum Snapshot Protocol](https://github.com/ethereum/devp2p/blob/master/caps/snap.md): enables exchange of snapshots between peers
- [Light Ethereum Subprotocol](https://github.com/ethereum/devp2p/blob/master/caps/les.md): protocol used by light clients
To debug and develop these networking components, Geth includes a command line tool called `devp2p`.
@ -25,8 +23,7 @@ This page will outline some of `devp2p`s built-in tools.
### ENR Decoding
Ethereum Node Records can be decoded, verified and displayed to the terminal using `enrdump`. It takes the ENR in its encoded form, which
is the base64 encoding of its RLP representation. A decoded human-readable text representation is displayed.
Ethereum Node Records can be decoded, verified and displayed to the terminal using `enrdump`. It takes the ENR in its encoded form, which is the base64 encoding of its RLP representation. A decoded human-readable text representation is displayed.
Use `devp2p enrdump <base64>` to verify and display an Ethereum Node Record.
@ -38,8 +35,7 @@ The `devp2p key ...` command family deals with node key files.
Run `devp2p key generate mynode.key` to create a new node key in the `mynode.key` file.
Run `devp2p key to-enode mynode.key -ip 127.0.0.1 -tcp 30303` to create an enode:// URL
corresponding to the given node key and address information.
Run `devp2p key to-enode mynode.key -ip 127.0.0.1 -tcp 30303` to create an enode:// URL corresponding to the given node key and address information.
### Maintaining DNS Discovery Node Lists
@ -53,28 +49,24 @@ Run `devp2p dns to-cloudflare <directory>` to publish a tree to CloudFlare DNS.
Run `devp2p dns to-route53 <directory>` to publish a tree to Amazon Route53.
More information about these commands can be found in the [DNS Discovery Setup Guide][dns-tutorial].
More information about these commands can be found in the [DNS Discovery Setup Guide](https://geth.ethereum.org/docs/developers/dns-discovery-setup).
### Node Set Utilities
There are several commands for working with JSON node set files. These files are generated
by the discovery crawlers and DNS client commands. Node sets also used as the input of the
DNS deployer commands.
There are several commands for working with JSON node set files. These files are generated by the discovery crawlers and DNS client commands. Node sets also used as the input of the DNS deployer commands.
Run `devp2p nodeset info <nodes.json>` to display statistics of a node set.
Run `devp2p nodeset filter <nodes.json> <filter flags...>` to write a new, filtered node
set to standard output. The following filters are supported:
Run `devp2p nodeset filter <nodes.json> <filter flags...>` to write a new, filtered node set to standard output. The following filters are supported:
- `-limit <N>` limits the output set to N entries, taking the top N nodes by score
- `-ip <CIDR>` filters nodes by IP subnet
- `-min-age <duration>` filters nodes by 'first seen' time
- `-eth-network <mainnet/rinkeby/goerli/ropsten>` filters nodes by "eth" ENR entry
- `-les-server` filters nodes by LES server support
- `-snap` filters nodes by snap protocol support
For example, given a node set in `nodes.json`, you could create a filtered set containing
up to 20 eth mainnet nodes which also support snap sync using this command:
For example, given a node set in `nodes.json`, you could create a filtered set containing up to 20 eth mainnet nodes which also support snap sync using this command:
The `devp2p discv4 ...` command family deals with the [Node Discovery v4][discv4]
protocol.
The `devp2p discv4 ...` command family deals with the [Node Discovery v4](https://github.com/ethereum/devp2p/tree/master/discv4.md) protocol.
Run `devp2p discv4 ping <enode/ENR>` to ping a node.
Run `devp2p discv4 resolve <enode/ENR>` to find the most recent node record of a node in
the DHT.
Run `devp2p discv4 resolve <enode/ENR>` to find the most recent node record of a node in the DHT.
Run `devp2p discv4 crawl <nodes.json path>` to create or update a JSON node set.
### Discovery v5 Utilities
The `devp2p discv5 ...` command family deals with the [Node Discovery v5][discv5]
protocol. This protocol is currently under active development.
The `devp2p discv5 ...` command family deals with the [Node Discovery v5](https://github.com/ethereum/devp2p/tree/master/discv5/discv5.md) protocol. This protocol is currently under active development.
Run `devp2p discv5 ping <ENR>` to ping a node.
Run `devp2p discv5 resolve <ENR>` to find the most recent node record of a node in
the discv5 DHT.
Run `devp2p discv5 resolve <ENR>` to find the most recent node record of a node in the discv5 DHT.
Run `devp2p discv5 listen` to run a Discovery v5 node.
Run `devp2p discv5 crawl <nodes.json path>` to create or update a JSON node set containing
discv5 nodes.
Run `devp2p discv5 crawl <nodes.json path>` to create or update a JSON node set containing discv5 nodes.
### Discovery Test Suites
The devp2p command also contains interactive test suites for Discovery v4 and Discovery
v5. To run these tests a networking environment must be set up with two separate UDP listening
addresses are available on the same machine. The two listening addresses must also be routed such
The devp2p command also contains interactive test suites for Discovery v4 and Discovery v5. To run these tests a networking environment must be set up with two separate UDP listening addresses are available on the same machine. The two listening addresses must also be routed such
that they are able to reach the node you want to test.
For example, to run the test on the local host when the node under test is
also on the local host, assign two IP addresses (or a larger range) to the
loopback interface. On macOS, this can be done by executing the following command:
For example, to run the test on the local host when the node under test is also on the local host, assign two IP addresses (or a larger range) to the loopback interface. On macOS, this can be done by executing the following command:
1. Start the node under test first, ensuring that it won't talk to the Internet (i.e. disable bootstrapping). An easy way to prevent
unintended connections to the global DHT is listening on `127.0.0.1`.
1. Start the node under test first, ensuring that it won't talk to the Internet (i.e. disable bootstrapping). An easy way to prevent unintended connections to the global DHT is listening on `127.0.0.1`.
2. Get the ENR of the node and store it in the `NODE` environment variable.
@ -133,21 +115,21 @@ unintended connections to the global DHT is listening on `127.0.0.1`.
### Eth Protocol Test Suite
The Eth Protocol test suite is a conformance test suite for the [eth protocol][eth].
The Eth Protocol test suite is a conformance test suite for the [eth protocol](https://github.com/ethereum/devp2p/blob/master/caps/eth.md).
To run the eth protocol test suite, the node needs to be initialized as follows:
1. initialize the geth node with the `genesis.json` file contained in the `testdata` directory
1. initialize the Geth node with the `genesis.json` file contained in the `testdata` directory
2. import the `halfchain.rlp` file in the `testdata` directory
@ -157,15 +139,12 @@ Repeat the above process (re-initialising the node) in order to run the Eth Prot
#### Eth66 Test Suite
The Eth66 test suite is also a conformance test suite for the eth 66 protocol version specifically.
To run the eth66 protocol test suite, initialize a geth node as described above and run the following command,
replacing `<enode>` with the enode of the geth node:
The Eth66 test suite is also a conformance test suite for the eth 66 protocol version specifically. To run the eth66 protocol test suite, initialize a Geth node as described above and run the following command, replacing `<enode>` with the enode of the Geth node:
This page introduced the DevP2P stack that defines Ethereum's peer-to-peer network and the `devp2p` command line tool that comes bundled with Geth. The `devp2p` tools enables Geth developers to work on the peer-to-peer network.
description: introduction to the private-network boot-strapping tool, Puppeth
---
Puppeth is a tool for quickly spinning up and managing private development networks. Puppeth gives fine-grained control over the network properties including the genesis block, signers, bootnodes, dashboards, etc but abstracts away the complexity of configuring it all manually.
Joe
2 years ago