6

I am running a private blockchain and I have parity nodes that seem to be connecting just fine. I've gotten though some geth issues that I was having before but geth still won't connect.

HOWEVER when I connect from the same computer with Parity, it seems to connect just fine.

Here is how I invoke geth the first time (not really port 9090 but that's for example):

./geth --datadir /path/to/custom --networkid 9090 --port 9090 init CustomGenesis.json

The CustomGenesis.json file has values that were manually taken from my Parity .json file, and I have successfully connected with Parity. So I believe those values are correct. I have used the items listed here, with the parity values: https://github.com/ethereum/go-ethereum/wiki/Private-network

I also have a file called /path/to/custom/static-nodes.json that lists the "enodes" of two existing Parity nodes.

ALSO, I have (sometimes separately and sometimes in addition to the static-nodes.json file) used the --bootnodes flag and listed the enodes of the parity nodes on the command line.

./geth --datadir /path/to/custom --networkid 9090 --port 9090 --ipcpath ~/.ethCustom/geth.ipc

However, these things happen/don't happen:

1) My other nodes do NOT show that a new node has entered the network

2) when I attach to the console at /path/to/custom/geth.ipc, and I run "admin.peers" I simply get "[]"

3) EXCEPT that once in a while I do get a peer, but it is not one of the peers on the custom network, but some seemingly random node with a port of 30303!! So weird! Why would 30303 be infiltrating my custom setup?

But when I type

admin.nodeInfo

I get a very satisfying output that shows the correct local enode; the same (correct) port for "listenAddr, listener, and discovery; the correct network id, and the corect difficulty.

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

  • 1
    I don't know if you solved this issue, but providing both genesis conf will be helpful. About 3) It's normal because 9090 is YOUR listening port, you are not forcing other nodes to listen on that port so every peer choose its own port (and 30303 is the default one). You see a rapid appear/disappear because nodes check each other to see if they are on the same net and in that case they start syncing. – Giuseppe Bertone Aug 29 '17 at 19:35
  • 1
    If the networkid is different, shouldn't they be invisible to each other? And exactly how do they "check each other to see if yhey are on the same net?" Maybe if I learn that, I will learn why my geth nodes won't connect. – stone.212 Aug 30 '17 at 9:14
  • 1
    NetworkId is one of the information that peers give each others to check if they are working on the same chain (they check also to have the same genesis block). So they NEED to be able to see each other, even if they are on different chains, or they can't check those informations at all. (if I can't speak to you, how can I know if you talk my language?) – Giuseppe Bertone Aug 30 '17 at 10:57
  • 1
    Just to check: parity nodes are already and coninuously syncing each others? There's at least a miner, and blocks in the cahin, and you expect only to see geth syncing like others parity nodes, right? – Giuseppe Bertone Aug 30 '17 at 11:01
  • 1
    @Giuseppe Bertone No miner yet but yes, Parity nodes show connection to each other. And yes I expect to set geth connecting to the other parity nodes. What you tell me about the genesis file tells me maybe the problem is that geth does not recognize the parity nodes because the chain spec is too much customized. – stone.212 Sep 1 '17 at 6:04
5

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

Next time tag your question with , 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.

  • 1
    Wow. Amazing reply. Answers so many things. Thank you. – stone.212 Sep 1 '17 at 9:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.