Parity Network – How to Get Enode URL to Use/Show External IP

enodeNetworkparity

When I run a (custom dev and test network) parity node on my mac from the command line, it starts up and displays my enode as enode://c2f9c6a...85b1d@192.168.0.241:99999 where the IP address is my router assigned ip 192.168.0.241.

This means that although I can connect to the bootnode peers which have been set up (I have a remote one on a VPS), and the bootnode peers record that my node is connected, no other remote nodes are able to connect to me using the enode URL that my node has.

For example, when other remote colleagues start their nodes, they also can connect to the bootnode, but are not able to discover my node nor am I able to discover them as they are also behind routers and they have the same issue. Therefore this is not a peer-to-peer network, it is centralised around the bootnode as node discovery appears not to be working.

So my question is actually two related questions, "How to get my enode URL to use/show external IP, and how can I be discoverable?", and if that is not possible then "how is peer-to-peer achieved on the public ethereum chain and can I apply it to my custom chain?".

Best Answer

There are a couple of issues here, that I hadn't outlined when I posted the question.

The first is that you may have other nodes running in your LAN that you may or may not be aware of - the external IP will be the same for all of them.
The second is that you should consider that being behind a router you want to route traffic to your node when it is required.
The third is that the question is more or less about being discovered on the network.

The question is therefore about if you want to host a permanent node or not.

Permanent Node

One reason to host a permanent node is if you want to host a bootnode for a network that can be connected to by anyone outside your LAN. You therefore need an external IP address, and you need to assure that there are no other nodes running behind your router that will also use the external IP address if not directly at least indirectly.

This solution in Parity requires setting the --nat extip:<your_external_ip> argument when you start up the node on the command line. This will force your node to startup and create an enode using your external IP and port.

This enode can then be included in your genesis.json file and will be used by other nodes to sync to the blockchain and other stuff.

Non-permanent node

This implies that you are starting and stopping your node at any time and you don't care too much about being available to the network or not.

Here you must consider what your router is doing. In this case you need to configure your router to have the port 30303 open (for ethereum or another value for your own private network) and port forwarding enabled for this port for both TCP and UDP.

This allows your node to both communicate with the network and be discoverable (UDP).

Related Solutions

[Ethereum] How does Ethereum client select which peers to synchronise with

Only a partial answer for the first couple of sub-questions...

How many nodes do we connect to?

The maximum number is set to 25 by default, but can be configured using the --maxpeers flag on the command line. This limit is flexible when taking into account "trusted" nodes. (See below.)

The finer detail is that we can also set the combined total of both pending incoming and outgoing connections using the --maxpendpeers flag. This is the number of nodes simultaneously performing connection handshakes, which may or may not be successful, and which depends on whether we can verify their identity. This is set to 66 by default (50 and 16 respectively).

What is the criteria for selecting which nodes to connect to?

There are three different categories of nodes that we connect to, though I'm unsure of the criteria they must meet (other than they must complete the handshake process):

Bootstrap nodes

// Bootstrap nodes are used to establish connectivity
// with the rest of the network.
BootstrapNodes []*discover.Node

Static nodes:

// Static nodes are used as pre-configured connections which are always
// maintained and re-connected on disconnects.
StaticNodes []*discover.Node

Trusted nodes:

// Trusted nodes are used as pre-configured connections which are always
// allowed to connect, even above the peer limit.
TrustedNodes []*discover.Node

admin.addPeer() allows you to add a new entry to the array of static nodes.

Go Ethereum – Geth Not Connecting to Private Network

What am I missing? Please let me know if there is other information I can supply. Thank you.

Next time tag your question with parity, to make sure I wont miss it :p

Cross-client private networks: The problem

Geth is a client written for Ethereum. It was one of the first official reference implementations and was never meant to run anything else but Ethereum. If you want to configure Geth for any other chain configuration, you would have to fork the source-code and create your own client implementation based on your desired rule-set. This happened for instance for Expanse (Gexp) and Ethereum Classic (Getc).

Parity, however, was created much later than Ethereum itself, by a team that was initially involved with the C++ Ethereum client (Eth). After they (Gavin Wood, et al.) founded Ethcore (now Parity), they created a client with a much broader vision, a client that is not supposed to only run Ethereum.

Parity allows more abstraction in the core and therefore, all you need to start a new chain is a so called Chain Specification file which describes the whole chain parameters, including consensus rules, validator engines, and so on. The most visible consequence is that Ethereum, Ethereum Classic, and Expanse (just to pick up the examples form above) do not need to maintain their own copy of the Parity source-code in order to support their project and their consensus rules. Parity just works out of the box with the --chain parameters foundation, classic, or expanse.

In addition, the --chain parameter allows configuring an entirely custom chain with pluggable consenus, custom transitions, and the validator engine you prefer.

In contrast, Geth only allows to specify a custom Genesis which is only one piece of the puzzle for a complete chain specification. And therefore you will have trouble to connect a Geth node to a custom network of Parity nodes. However, you basically have two options to run a custom cross-client network with both Geth and Parity nodes, explained below.

Best-practice: "Geth First"

Now, since you have fewer chain configuration options in Geth than in Parity, I'll call the most obvious idea "Geth First". You chose a network ID and create a custom Genesis, and initialize your new network with geth init. You can fire up a miner thread and a couple more Geth nodes at this point to verify the network is exactly what you need.

Now, you can start integrating Parity nodes. There is a tiny rust tool keorn/parity-spec that converts your custom Geth genesis file into a full Parity chain specification file.

cargo run -- geth-genesis.json

You can pass the output parity-spec.json directly to you Parity node with the --chain parameter. For discovery, you can use Geth's admin.addPeer() commands or Parity's --reserved-peers functionality.

However, both Geth and Parity are actively developed code-bases and the converter tool is prone to bugs and often users report generated chain-specification files are still leading to consensus issues. If this happens to you frequently, check out the other option below.

Best-practice: "Ropsten Revived - Revived"

The probably most stable and most obvious option to run a private network compatible with Geth, Parity, and probably all other clients out there, is something, I would call "Ropsten Revived - Revived".

Just take known, working network that is supported by all clients, like the Ropsten public testnet, and slightly modify it. To ease this process, I created presets for both the Genesis and the Parity Chain Specification at 5chdn/crossclient-chainsepc. It contains a geth.json and a parity.json mimicking a Ropsten revival with network ID 1337 (0x539).

The downside of this is probably the unsatisfied desire to add more complex modifications to your custom private development network. However, the predefined genesis and chain-spec offer a good starting point to get you bootstrapped with whatever network you have in mind.