update "Connecting to network" page (#24893)
* update "connecting to network" page * fix typo Co-authored-by: Martin Holst Swende <martin@swende.se> * fix links * reorder connectivity problems * rm code snippet for custom networks * fix typo * fix disc/RLPx text from S1na review previously erroneously suggested subprotocol negotiation was part of discovery. * rm uneccessary commands (static & trusted nodes) Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com>
This commit is contained in:
Joseph Cook
GitHub
parent
896de88f35
commit
1a2acaa038
|
|
@ -3,72 +3,71 @@ title: Connecting To The Network
|
|||
sort_key: B
|
||||
---
|
||||
|
||||
If you start geth without any flags, it will connect to the Ethereum mainnet. In addition to
|
||||
the mainnet, geth recognizes a few testnets which you can connect to via the respective flags:
|
||||
The default behaviour for Geth is to connect to Ethereum Mainnet. However, Geth can also connect to public testnets, [private networks](/docs/getting-started/private-net) and [local testnets](/docs/getting-started/dev-mode). Command line flags are provided for connecting to the popular public testnets:
|
||||
|
||||
- `--ropsten`, Ropsten proof-of-work test network
|
||||
- `--rinkeby`, Rinkeby proof-of-authority test network
|
||||
- `--goerli`, Goerli proof-of-authority test network
|
||||
- `--sepolia` Sepolia proof-of-work test network
|
||||
|
||||
**Note:** network selection is not persisted in the config file. To connect to a pre-defined network
|
||||
you must always enable it explicitly, even when using the `--config` flag to load other configuration values.
|
||||
For example:
|
||||
Providing these flags at startup instructs Geth to connect to the specific public testnet instead of Ethereum Mainnet. Because these are public testnets that have been running for several years, Geth has to download the historical blockchain data from genesis, just the same as for Ethereum Mainnet.
|
||||
|
||||
**Note:** network selection is not persisted in the config file. To connect to a pre-defined network you must always enable it explicitly, even when using the `--config` flag to load other configuration values. For example:
|
||||
|
||||
```shell
|
||||
|
||||
```sh
|
||||
# Generate desired config file. You must specify testnet here.
|
||||
geth --goerli --syncmode "full" ... dumpconfig > goerli.toml
|
||||
|
||||
# Start geth with given config file. Here too the testnet must be specified.
|
||||
geth --goerli --config goerli.toml
|
||||
|
||||
```
|
||||
|
||||
## How Peers Are Found
|
||||
## Finding peers
|
||||
|
||||
Geth continuously attempts to connect to other nodes on the network until it has peers. If
|
||||
you have UPnP enabled on your router or run ethereum on an Internet-facing server, it will
|
||||
also accept connections from other nodes.
|
||||
Geth continuously attempts to connect to other nodes on the network until it has enough peers. If UPnP (Universal Plug and Play) is enabled at the router or Ethereum is run on an Internet-facing server, it will also accept connections from other nodes. Geth finds peers using the [discovery protocol](https://ethereum.org/en/developers/docs/networking-layer/#discovery). In the discovery protocol, nodes exchange connectivity details and then establish sessions ([RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md)). If the nodes support compatible sub-protocols they can start exchanging Ethereum data [on the wire](https://ethereum.org/en/developers/docs/networking-layer/#wire-protocol).
|
||||
|
||||
Geth finds peers through something called the discovery protocol. In the discovery
|
||||
protocol, nodes are gossipping with each other to find out about other nodes on the
|
||||
network. In order to get going initially, geth uses a set of bootstrap nodes whose
|
||||
endpoints are recorded in the source code.
|
||||
A new node entering the network for the first time gets introduced to a set of peers by a bootstrap node ("bootnode") whose sole purpose is to connect new nodes to peers. The endpoints for these bootnodes are hardcoded into Geth, but they can also be specified by providing the `--bootnode` flag along with comma-separated bootnode addresses in the form of [enodes](https://ethereum.org/en/developers/docs/networking-layer/network-addresses/#enode) on startup. For example:
|
||||
|
||||
To change the bootnodes on startup, use the `--bootnodes` option and separate the nodes by
|
||||
commas. For example:
|
||||
```shell
|
||||
|
||||
geth --bootnodes enode://pubkey1@ip1:port1,enode://pubkey2@ip2:port2,enode://pubkey3@ip3:port3
|
||||
geth --bootnodes enode://pubkey1@ip1:port1,enode://pubkey2@ip2:port2,enode://pubkey3@ip3:port3
|
||||
|
||||
## Common Problems With Connectivity
|
||||
```
|
||||
|
||||
Sometimes you just can't get connected. The most common reasons are as follows:
|
||||
There are scenarios where disabling the discovery process is useful, for example for running a local test node or an experimental test network with known, fixed nodes. This can be achieved by passing the `--nodiscover` flag to Geth at startup.
|
||||
|
||||
- Your local time might be incorrect. An accurate clock is required to participate in the
|
||||
Ethereum network. Check your OS for how to resync your clock (example `sudo ntpdate -s
|
||||
time.nist.gov`) because even 12 seconds too fast can lead to 0 peers.
|
||||
- Some firewall configurations can prevent UDP traffic from flowing. You can use the
|
||||
static nodes feature or `admin.addPeer()` on the console to configure connections by
|
||||
hand.
|
||||
|
||||
To start geth without the discovery protocol, you can use the `--nodiscover` parameter.
|
||||
You only want this if you are running a test node or an experimental test network with
|
||||
fixed nodes.
|
||||
## Connectivity problems
|
||||
|
||||
There are occasions when Geth simply fails to connect to peers. The common reasons for this are:
|
||||
|
||||
- Local time might be incorrect. An accurate clock is required to participate in the Ethereum network. The local clock can be resynchronized using commands such as `sudo ntpdate -s time.nist.gov` (this will vary depending on operating system).
|
||||
|
||||
- Some firewall configurations can prohibit UDP traffic. The static nodes feature or `admin.addPeer()` on the console can be used to configure connections manually.
|
||||
|
||||
- Running Geth in [light mode](/docs/interface/les) often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Geth out of light mode.
|
||||
|
||||
- The public test network Geth is connecting to might be deprecated or have a low number of active nodes that are hard to find. In this case, the best action is to switch to an alternative test network.
|
||||
|
||||
|
||||
## Checking Connectivity
|
||||
|
||||
To check how many peers the client is connected to in the interactive console, the `net`
|
||||
module has two attributes that give you info about the number of peers and whether you
|
||||
are a listening node.
|
||||
The `net` module has two attributes that enable checking node connectivity from the [interactive Javascript console](/docs/interface/javascript-console). These are `net.listening` which reports whether the Geth node is listening for inbound requests, and `peerCount` which returns the number of active peers the node is connected to.
|
||||
|
||||
|
||||
```javascript
|
||||
|
||||
```js
|
||||
> net.listening
|
||||
true
|
||||
|
||||
> net.peerCount
|
||||
4
|
||||
|
||||
```
|
||||
|
||||
To get more information about the connected peers, such as IP address and port number,
|
||||
supported protocols, use the `peers()` function of the `admin` object. `admin.peers()`
|
||||
returns the list of currently connected peers.
|
||||
Functions in the `admin` module provide more information about the connected peers, including their IP address, port number, supported protocols etc. Calling `admin.peers` returns this information for all connected peers.
|
||||
|
||||
```
|
||||
> admin.peers
|
||||
|
|
@ -100,7 +99,7 @@ returns the list of currently connected peers.
|
|||
|
||||
```
|
||||
|
||||
To check the ports used by geth and also find your enode URI run:
|
||||
The `admin` module also includes functions for gathering information about the local node rather than its peers. For example, `admin.nodeInfo` returns the name and connectivity details for the local node.
|
||||
|
||||
```
|
||||
> admin.nodeInfo
|
||||
|
|
@ -118,67 +117,49 @@ To check the ports used by geth and also find your enode URI run:
|
|||
|
||||
## Custom Networks
|
||||
|
||||
Sometimes you might not need to connect to the live public network, you can instead choose
|
||||
to create your own private testnet. This is very useful if you don't need to test external
|
||||
contracts and want just to test the technology, because you won't have to compete with
|
||||
other miners and will easily generate a lot of test ether to play around (replace 12345
|
||||
with any non-negative number):
|
||||
It is often useful for developers to connect to private test networks rather than public testnets or Etheruem mainnet. These sandbox environments allow block creation without competing against other miners, easy minting of test ether and give freedom to break things without real-world consequences. A private network is started by providing a value to `--networkid` that is not used by any other existing public network ([Chainlist](https://chainlist.org)) and creating a custom `genesis.json` file. Detailed instructions for this are available on the [Private Networks page](/docs/interface/private-network).
|
||||
|
||||
geth -—networkid="12345" console
|
||||
|
||||
It is also possible to run geth with a custom genesis block from a JSON file by supplying
|
||||
the `geth init /path/to/file` command. The genesis JSON file should have the following format:
|
||||
|
||||
```js
|
||||
{
|
||||
"alloc": {
|
||||
"dbdbdb2cbd23b783741e8d7fcf51e459b497e4a6": {
|
||||
"balance": "1606938044258990275541962092341162602522202993782792835301376"
|
||||
},
|
||||
"e6716f9544a56c530d868e4bfbacb172315bdead": {
|
||||
"balance": "1606938044258990275541962092341162602522202993782792835301376"
|
||||
},
|
||||
...
|
||||
},
|
||||
"nonce": "0x000000000000002a",
|
||||
"difficulty": "0x020000",
|
||||
"mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"coinbase": "0x0000000000000000000000000000000000000000",
|
||||
"timestamp": "0x00",
|
||||
"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"extraData": "0x",
|
||||
"gasLimit": "0x2fefd8"
|
||||
}
|
||||
```
|
||||
|
||||
## Static nodes
|
||||
|
||||
Geth also supports a feature called static nodes if you have certain peers you always want
|
||||
to connect to. Static nodes are re-connected on disconnects. You can configure permanent
|
||||
static nodes by putting something like the following into
|
||||
`<datadir>/geth/static-nodes.json`:
|
||||
Geth also supports static nodes. Static nodes are specific peers that are always connected to. Geth reconnects to these peers automatically when it is restarted. Specific nodes are defined to be static nodes by saving their enode addresses to a json file which must be stored in `datadir/geth/static-nodes.json`. The content of `static-nodes.json` should be formatted as follows:
|
||||
|
||||
```js
|
||||
```javascript
|
||||
[
|
||||
"enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303",
|
||||
"enode://pubkey@ip:port"
|
||||
]
|
||||
```
|
||||
|
||||
You can also add static nodes at runtime via the js console using
|
||||
`admin.addPeer()`:
|
||||
Static nodes can also be added at runtime in the Javascript console by passing an enode address to `admin.addPeer()`:
|
||||
|
||||
```javascript
|
||||
|
||||
```js
|
||||
admin.addPeer("enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303")
|
||||
|
||||
```
|
||||
|
||||
## Peer limit
|
||||
|
||||
It is sometimes desirable to cap the number of peers Geth will connect to in order to limit on the computational and bandwidth cost associated with running a node. By default, the limit is 50 peers, however, this can be updated by passing a value to `--maxpeers`:
|
||||
|
||||
```shell
|
||||
|
||||
geth <otherflags> --maxpeers 15
|
||||
|
||||
```
|
||||
|
||||
## Trusted nodes
|
||||
|
||||
Geth supports trusted nodes that are always allowed to reconnect, even if the peer limit is reached.
|
||||
They can be added permanently via a config file `<datadir>/geth/trusted-nodes.json` or temporary via RPC call.
|
||||
The format for the config file is identical to the one used for static nodes.
|
||||
Nodes can be added using the `admin.addTrustedPeer()` RPC-call over the js console and removed using the `admin.removeTrustedPeer()` call.
|
||||
Geth supports trusted nodes that are always allowed to reconnect, even if the peer limit is reached. They can be added persistently via a config file `<datadir>/geth/trusted-nodes.json` or temporarily using the Javascript console. The format for the config file is identical to the one used for static nodes.
|
||||
|
||||
```js
|
||||
Nodes can be added using the `admin.addTrustedPeer()` call in the Javascript console and removed using `admin.removeTrustedPeer()` call.
|
||||
|
||||
```javascript
|
||||
admin.addTrustedPeer("enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303")
|
||||
```
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
Geth connects to Ethereum Mainnet by default. However, this behaviour can be changed using combinations of command line flags and files. This page has described the various options available for connecting a Geth node to Ethereum, public testnets and private networks.
|
||||
|
|
|
|||
Loading…
Reference in New Issue