Ropsten Node – Cannot Connect to Ethereum Ropsten Testnet Node

go-ethereumnodejs

I installed Ropsten (revival) testnet on an Ubuntu server, Then I start my testnet node:

geth --testnet

I can connect to my node via

geth attach ipc:/home/myusername/.ethereum/testnet/geth.ipc

and I get this info from my node instance:

> admin.nodeInfo
{
  enode: "enode://03aa54...0689be3@24.230.213.120:30303",
  id: "03aa54b894aec...a49d8490689be3",
  ip: "www.xxx.yyy.zzz",
  listenAddr: "[::]:30303",
  name: "Geth/v1.6.7-stable-ab5646c5/linux-amd64/go1.8.1",
  ports: {
    discovery: 30303,
    listener: 30303
  },
  protocols: {
    eth: {
      difficulty: 1621387497788667,
      genesis: "0x41941023680923e0fe4d74a34bdac8141f2540e3ae90623718e47d66d1ca4a2d",
      head: "0x84e8e85cdd7a5fa79d26b9fa89cd850be23b13d2079208e052eceb06c436654b",
      network: 3
    }
  }
}

But I cannot connect to the testnet node from my nodejs script:

Web3 = require("web3");
web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:30303"));
console.log(web3.isConnected());

always return false !
Any advice ?

Best Answer

The port 30303 is used by the client (TCP as listener and UDP for discovery) to communicate in the peer to peer protocol.

For Web3, you must use the JSON-RPC port (by default 8545) which can be enabled with the following parameter --rpc

Command:

geth --testnet --rpc --rpcapi "eth,net,web3" --rpccorsdomain '*' --rpcaddr 127.0.0.1 --rpcport 8545

Then you can try to run:

Web3 = require("web3");
web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
console.log(web3.isConnected());

More details

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.

[Ethereum] Restarting geth node, doesn’t work properly with cron nor Ubuntu upstart service

It sounds like the socket is not connected to your geth instance. I saw here that geth.ipc could cause problems, you can try:

rm -f /home/my_local_username/.ethereum/testnet/geth.ipc

I don't see the bug myself but this socket stays when hard killing geth and could be in a bad state for you. You should also check the logs on starting geth to see if any socket warnings or errors are raised.

Best Answer

Related Solutions

Go Ethereum – Geth Not Connecting to Private Network

Cross-client private networks: The problem

Best-practice: "Geth First"

Best-practice: "Ropsten Revived - Revived"

[Ethereum] Restarting geth node, doesn’t work properly with cron nor Ubuntu upstart service

Related Topic