2

Lets say, that there are two networks, Ethereum 1 and Ethereum 2, and they have different blockchains.

How would you configure both networks the way that nodes wouldn't collide with when discovering each other? Because if networks have thousands of nodes, checking chainID is a very time consuming task, there would be a lot of wasted resources if both networks collide with each other.

EDIT: or , in other words, how to you make it that both networks don't interchange TCP / UDP traffic and avoid collisions this way?

Improve this question
16
  • It could be one answer : In peer to peer networks, the peer discovery often use proxy discovery (node discover other nodes via the connection of his know peers). For example if A and B (on the same network Eth 1) are connected and B is connected to C, B will indicate to A that C is also connected. So A will add C in his peer network. So if everyone (of Eth 1) is initially connect to the bootstrap node of Eth 1, everybody will stay in Eth 1 and it will be impossible for two elements of the 2 distinct blockchains to collude (they will never be in contact of each other).
    – Adrien Forbu
    Oct 22, 2017 at 20:41
  • Unless someone explicitly adds a node from the second network using the --bootnodes flag... :-)
    – Richard Horrocks
    Oct 22, 2017 at 21:01
  • @RichardHorrocks, this doesn't work. Tried it. There is still a lot of traffic going , which you can see if you activate debug.verbosity(6)
    – Nulik
    Oct 22, 2017 at 21:03
  • I meant you can bypass the separation provided by the discovery protocols by deliberately using a node from another network as a bootnode. It used to work (or at least it didn't used to complain), even if they wouldn't talk to each other because of the subsequent handshake failure.
    – Richard Horrocks
    Oct 22, 2017 at 21:08
  • @RichardHorrocks, well, my private net has bootnodes. my geth client is connected to the bootnode and everything is working ok. But I can see lots of PING/PONG in the log from hundreds of unknown IP addresses. I don't think someone even knows my bootnode IP because my net is not yet public, so this is not the case. I think there is some problem with the discovery mechanism that creates a lot of unnecessary traffic when you use private net.
    – Nulik
    Oct 22, 2017 at 21:27

3 Answers 3

Reset to default
2

I have found an easy solution to make your private network isolated. It does not prevent UDP packet flow, but it does prevent incoming TCP connections. The solution is to change the discovery protocol constants for packet types, so the other network would not understand you. You just have to modify this line of code in p2p/discover/udp.go:

pingPacket = iota + 1 // zero is 'reserved'

adding a constant that is larger than 4, for example:

// RPC packet types
const (
    pingPacket = iota + 64
    pongPacket 
    findnodePacket 
    neighborsPacket 
)

The result is this:

DEBUG[10-23|20:05:32] Bad discv4 packet                        addr=34.236.33.177:30303   err="unknown type: 1"
DEBUG[10-23|20:05:32] Bad discv4 packet                        addr=212.170.201.113:30399 err="unknown type: 1"
DEBUG[10-23|20:05:32] Bad discv4 packet                        addr=41.182.132.197:30399  err="unknown type: 1"
DEBUG[10-23|20:05:33] Bad discv4 packet                        addr=94.63.228.3:30399     err="unknown type: 1"
DEBUG[10-23|20:05:33] Bad discv4 packet                        addr=77.221.88.207:30303   err="unknown type: 1"
DEBUG[10-23|20:05:34] Bad discv4 packet                        addr=86.174.184.92:30399   err="unknown type: 1"
DEBUG[10-23|20:05:34] Bad discv4 packet                        addr=97.91.252.163:30399   err="unknown type: 1"
DEBUG[10-23|20:05:34] Bad discv4 packet                        addr=84.237.99.182:2931    err="unknown type: 1"

Since the rule is to receive a PONG from a PING before connecting, the dialing nodes never get a PONG and the discovery mechanism fails. It only works with your own nodes.

Improve this answer
1
  • +1 for working this out. I notice that there's a discussion going on under issue #15358, and that there's ongoing work on the new version of the discovery protocol. Maybe mark your own answer as accepted, and follow things on that thread :-) (Can always update this answer once the changes to the protocol have been made.)
    – Richard Horrocks
    Oct 24, 2017 at 8:18
1

This occurs in real time as blocks are being propagated through the network. When a node receives a newly mined block, it will check for the previous block header (the hash of the previously chained block) and accept that block as valid if it contains the correct parent block hash.

So if there two networks Ethereum 1 and Ethereum 2 nodes on each network will know which blocks are for them based the parent block hash included in the newly mined block.

EDIT:

Sorry I didn't read your question correctly. For peer discovery there is a protocol in the Ethereum code for confirming a handshake with another node. It is basically a value that has to be sent along the wire with any other information. So when you boot up an Ethereum node and it goes searching for other nodes on the same port, it will receive a protocol message as specified in the Ethereum code.

Improve this answer
2
  • Are you saying that to make it that both network don't see each other it is enough to change the port number from 30303 to , say 40404 ? This way they wouldn't ever cross a TCP packet between them, right ?
    – Nulik
    Oct 22, 2017 at 20:51
  • No that needs to be done in general, but clients could always switch ports whenever they feel like it. The real know comes from the handshake protocol which (per the code) requires certain messages to be exchanged during peer discovery.
    – jojeyh
    Oct 22, 2017 at 20:54
0

Edit the params bootnode.go file, as other people have suggested. I replaced all the public bootnodes with my private bootnode IP (All my nodes and bootnode are inside my LAN) Then recompile the geth and bootnode binary. You also have to delete the nodes cache/folder from your datadir, on every node. Then install the new geth binary on every node. I restarted all my nodes with the bootnode option (pointing to my private bootnode) and discovery mode is ON. I let all the nodes p2p connect successfully. I stopped one of the nodes and restarted it without the bootnode option and it successfully reconnected to my private network without calling any mainnet/testnet bootnodes. In the past (geth compiled with mainnet bootnode IPs) my nodes would constantly try to connect out to mainnet if I forgot the bootnode option and/or nodiscovery option. People who have edited the bootnodes param file and still have issues are probably forgetting to clear their nodes cache/folder or are leaving their listening port (default 30303) exposed to the WAN (Internet)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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