I'm confused between the two objects.
As I know, peer is the object or node.
But when we create an Ethereum network, at each node, I have to add a peer.
So it means there is a difference between node and peer.
Please help me. Thanks.
nodespeers
I'm confused between the two objects.
As I know, peer is the object or node.
But when we create an Ethereum network, at each node, I have to add a peer.
So it means there is a difference between node and peer.
Please help me. Thanks.
Q: I know that when a new geth instance runs it connects to the bootstrap nodes. What I want to know that do other nodes download blockchain from the bootstrap nodes or nor?
A: No. Regular nodes do not download the blockchain from bootnodes. The only role for the bootnodes is to allow regular nodes to connect to and get the connection information on other regular nodes. The regular nodes will then use this information to connect to other regular nodes.
Q: Bootstrap nodes are highly available so why just simply connect to bootstrap nodes instead of connecting to some other node in the network.
A: The bootnode's only role is to provide the connection information for regular nodes to connect to each other. The connection information for several bootnodes are hard-coded into the regular node source code - see bootnodes.go
As the bootnodes only serve very little information to each regular node, the bootnode server resources can be focussed on providing this information and not get bogged down transferring the blockchain data.
Q What if bootstrap nodes provide wrong information. The whole network is compromised right?
A Not necessarily. You are able to specify new bootnodes on the command line parameters of the regular node client:
geth help | grep bootnode
--bootnodes value Comma separated enode URLs for P2P discovery bootstrap
You are also able to manually enter a list of other regular nodes on the network using the admin.addPeer(...)
command.
Recently many users reported that their regular nodes was not able to find peers. There were some problems with the bootnodes. See geth does not sync out of the box.
The temporary workaround was to get a list of regular node connection information from peers that were already connected to peers, and pasting this connection information into the regular node that was experiencing the peer discovery problem. See How can I create a list of peers from my syncing geth node to manually paste into my non-syncing geth node using the admin.addPeer() command?.
Q: How is a regular node different than a bootstrap node?
A The regular node has the peer discovery mechanism of the bootstrap node. Additionally, the regular node will download and synchronise the blockchain with other regular nodes. The bootstrap node cannot be used directly to synchronise the blockchain.
Q: And also How does peer discovery actually works?
A: See Node discovery protocol and What are the peer discovery mechanisms involved in Ethereum?
Q: What if nodes only download and not upload?
A: There are sufficient nodes (~6,000) on the network that your node should find other nodes to download from.
Q: What if I execute a denial of service attack which connect to many nodes in the network and downloads blockchain?
A: You will need a lot of computing and networking resources to try to execute a denial of service attack on ~6,000 nodes.
From What is the Difference Between 127.0.0.1 and 0.0.0.0?:
What is the Difference Between 127.0.0.1 and 0.0.0.0?
- 127.0.0.1 is the loopback address (also known as localhost).
- 0.0.0.0 is a non-routable meta-address used to designate an invalid, unknown, or non-applicable target (a ‘no particular address’ place holder).
In the context of a route entry, it usually means the default route.
In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.
What you want to do is to find the IP address of the machines that is non-127.0.0.1 which will look like on OS/X (and Linux):
Iota:~ bok$ ifconfig -a
...
inet 127.0.0.1 netmask 0xff000000
...
inet 192.168.0.11 netmask 0xffffff00 broadcast 192.168.0.255
On Windows, the equivalent command is ipconfig /all
.
The 192.168.0.11 address is the one you want to use in your enode string as this is the IP address of the machine that is contactable by your the other computers on your network.
You will then need to add your peer using a command like:
> admin.addPeer("enode://5d272e8bee6d29dfff6313999a4a2c3d8109ae6f3eb103480f4536c0542549b9fa12a8d8ae5ebee9c4db55cab553693b04eedbc9b29f35bbc0af1956231b42b4@192.168.0.11:30303")
Here's a step-by-step example of running 2 miners on the same computer under OS/X, with the miners communicating with each other. You should be able to replicate this in Windows and Linux. You should also be able to replicate this on more than 2 nodes, and on separate computers.
Update Oct 31 2016 00:00:56 UTC You may encounter a problem with the DAG generation as both miners will try to create the DAG at the same time in the same file. On OS/X (and Linux), the DAG file is stored in $HOME/.ethash
. This is the same problem as described in Private chain, two geth miner on the same machine, second miner throws "panic: ethash_full_new IO or memory error" . The workaround is to start the second miner after the first miner has completed creating the DAG - when the initial DAG needs to be created. A new DAG will need to be created periodically and this may cause one of your miners to crash.
The details:
geth version
reports 1.4.18-stable-c72f5459
/tmp/Test2Miners
, with miner #1's data directory being /tmp/Test2Miners/miner1data
and miner #2's data directory being /tmp/Test2Miners/miner2data
.I created the file /tmp/Test2Miners/genesis.json
with the following contents:
{
"config": {
"homesteadBlock": 10
},
"nonce": "0",
"difficulty": "0x400",
"mixhash": "0x00000000000000000000000000000000000000647572616c65787365646c6578",
"coinbase": "0x0000000000000000000000000000000000000000",
"timestamp": "0x00",
"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"extraData": "0x",
"gasLimit": "0x3B4A1B44",
"alloc": {}
}
I created /tmp/Test2Miners/testpassword
with the following contents:
aaaargh
I created /tmp/Test2Miners/initMiner1
with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/initMiner1
:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner1data init /tmp/Test2Miners/genesis.json
geth --datadir /tmp/Test2Miners/miner1data --password /tmp/Test2Miners/testpassword account new
I created /tmp/Test2Miners/initMiner2
with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/initMiner2
:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner2data init /tmp/Test2Miners/genesis.json
geth --datadir /tmp/Test2Miners/miner2data --password /tmp/Test2Miners/testpassword account new
I created /tmp/Test2Miners/runMiner1
with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/runMiner1
:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner1data --unlock 0 --password /tmp/Test2Miners/testpassword --mine --minerthreads 1 --port 30301 console
I created /tmp/Test2Miners/runMiner2
with the following contents, then set the executable bit using the command chmod 700 /tmp/Test2Miners/runMiner2
:
#!/bin/sh
geth --datadir /tmp/Test2Miners/miner2data --unlock 0 --password /tmp/Test2Miners/testpassword --mine --minerthreads 1 --port 30302 console
I initialised the data directories and created the first account (coinbase) for both miners using the command:
/tmp/Test2Miners/initMiner1
/tmp/Test2Miners/initMiner2
In terminal window #1, I started miner #1 using the following command. I've included the enode information printed on the console, which can also be determined by using the admin.nodeInfo
command:
/tmp/Test2Miners/runMiner1
...
enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@[::]:30301
In terminal window #2, I started miner #2 using the command:
/tmp/Test2Miners/runMiner2
...
enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@[::]:30302
I've replaced the [::]
in the enode strings with the local IP address, so my admin.addPeer(...)
commands would look like:
admin.addPeer("enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@192.168.1.11:30301")
and
admin.addPeer("enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@192.168.1.11:30302")
I pasted the admin.addPeer(...)
with the enode string from the miner #1 into the miner#2 console.
In the miner #1 console:
> admin.peers
[{
caps: ["eth/62", "eth/63"],
id: "b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436",
name: "Geth/v1.4.18-stable-c72f5459/darwin/go1.7.1",
network: {
localAddress: "192.168.1.11:30301",
remoteAddress: "192.168.1.11:62922"
},
protocols: {
eth: {
difficulty: 152346260,
head: "0x8296dbd46fe12cef1415c27cb21f2ad6d70b6ee174977529eaf266c3488e6e2e",
version: 63
}
}
}]
Success!
And in the miner #2 console:
> admin.peers
[{
caps: ["eth/62", "eth/63"],
id: "dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d",
name: "Geth/v1.4.18-stable-c72f5459/darwin/go1.7.1",
network: {
localAddress: "192.168.1.11:62922",
remoteAddress: "192.168.1.11:30301"
},
protocols: {
eth: {
difficulty: 157293798,
head: "0xd9b044d4e996407ff94b075c36b845db219078c64e7898e628983496d46067bf",
version: 63
}
}
}]
Confirm success!
Here is the console log from one of the miners:
I1031 00:53:27.604563 miner/worker.go:435] 🔨 🔗 Mined 5 blocks back: block #1447
I1031 00:53:27.605050 miner/worker.go:539] commit new work on block 1453 with 0 txs & 0 uncles. Took 460.253µs
I1031 00:53:29.682117 core/blockchain.go:1001] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 12.081834ms. #1453 [3a94659b / 3a94659b]
I1031 00:53:29.683526 miner/worker.go:539] commit new work on block 1454 with 0 txs & 0 uncles. Took 1.167337ms
I1031 00:53:29.683565 miner/worker.go:435] 🔨 🔗 Mined 5 blocks back: block #1448
The 3rd line shows that the other miner has mined a block, and this miner is importing the block. The other lines show that this miner is mining the blocks.
To automate the peer-to-peer discovery, I create /tmp/Test2Miners/miner1data/static-nodes.json
with the following information (reference
Static nodes):
[
"enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@192.168.1.11:30301",
"enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@192.168.1.11:30302"
]
and I copy this file to /tmp/Test2Miners/miner2data/static-nodes.json
.
I restart both miners using the /tmp/Test2Miners/runMiner1
and /tmp/Test2Miners/runMiner2
commands in separate terminal windows and check that they are connected to each other using the admin.peers
and they are. Success++.
Best Answer
It's a language thing about the relationship. It's like "people" and "friends". It's not that friends aren't also people. We might say that people are friends because they have a certain relationship to us.
Ethereum nodes are initially alone, and then they seek out other nodes to talk to. When nodes agree to talk, they become peers to each other.
"Peers" is another word for a person just like me with similar knowledge and abilities. A node's peers are other nodes that work the same way. Nodes talk to the network through their peers, and learn about the network from their peers.
Hope it helps.