Generate some random ID, e.g. using random dot org, let's use 88259
. On the first machine your run the client like that (note I also changed the network port and datadir to avoid conflicts with the main network):
geth --datadir "/home/user/.eth-private" --port 30259 --networkid 88259
This will run a new instance of a private ethereum network on your first machine.
I0621 10:19:02.655014 ethdb/database.go:82] Alloted 128MB cache and 1024 file handles to /home/user/.eth-private/chaindata
I0621 10:19:02.827145 ethdb/database.go:169] closed db:/home/user/.eth-private/chaindata
I0621 10:19:02.827243 cmd/utils/flags.go:601] WARNING: No etherbase set and no accounts found as default
I0621 10:19:02.827886 ethdb/database.go:82] Alloted 128MB cache and 1024 file handles to /home/user/.eth-private/chaindata
I0621 10:19:02.840042 ethdb/database.go:82] Alloted 16MB cache and 16 file handles to /home/user/.eth-private/dapp
I0621 10:19:02.841749 eth/backend.go:172] Protocol Versions: [63 62 61], Network Id: 88259
I0621 10:19:02.841907 eth/backend.go:201] Blockchain DB Version: 3
I0621 10:19:02.842241 core/blockchain.go:206] Last header: #0 [d4e56740…] TD=17179869184
I0621 10:19:02.842260 core/blockchain.go:207] Last block: #0 [d4e56740…] TD=17179869184
I0621 10:19:02.842271 core/blockchain.go:208] Fast block: #0 [d4e56740…] TD=17179869184
I0621 10:19:02.842952 p2p/server.go:313] Starting Server
I0621 10:19:04.844709 p2p/discover/udp.go:217] Listening, enode://6179e58bb512415a76e4169dd25ae5a171e34069660b233cf79dabd3581d8dd1221a7f3a5e5d64251aa7e8ac20eda5430e42eed161e68cb05d05e6c3cab68a6e@[::]:30259
I0621 10:19:04.845128 p2p/server.go:556] Listening on [::]:30259
I0621 10:19:04.848679 node/node.go:296] IPC endpoint opened: /home/user/.eth-private/geth.ipc
Now, you extract the enode uri from the first node and replace the IP with the ID of your local area network (LAN, or use the public IP if the nodes are distributed), like that:
enode://6179e58bb512415a76e4169dd25ae5a171e34069660b233cf79dabd3581d8dd1221a7f3a5e5d64251aa7e8ac20eda5430e42eed161e68cb05d05e6c3cab68a6e@192.168.1.159:30259
Now, you can pass this node as boot node to the 2nd and 3rd node, like that:
geth --datadir "/home/user/.eth-private" --port 30259 --networkid 88259 --bootnodes "enode://6179e58bb512415a76e4169dd25ae5a171e34069660b233cf79dabd3581d8dd1221a7f3a5e5d64251aa7e8ac20eda5430e42eed161e68cb05d05e6c3cab68a6e@192.168.1.159:30259"
Note the network ID has to be the same on all clients. It will try to connect to your first node.
If you have multiple nodes running, you can also add more nodes to the bootnodes parameter, just separate them by comma.
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.
Best Answer
You can do it with using both ways, having the two computers networked together.
Using Metamask;
select network as Custom RPC put the custom url as
http://[ComputerA's ip address]:[rpc port]
eg:
If computer A's ip address is
192.168.8.100
and rpc port is8545
then use,http://192.168.8.100:8545
Using web3;
As one of your own questions How can I connect my HTML user interface to my Ethereum private chain? you can use
with the slight change of; instead
localhost
replace the ip address of the other computer (in your case computer A's ip address in the LAN) and the 8545 with port number.eg:
If computer A's ip address is
192.168.8.101
and rpc port is8545
then use,EDIT: It's needed to have RPC enabled in the computer A allowing the computer B to access it with