Analysis of Geth 1.6.6v’s P2P network
- create UDP/TCP listener
- schedule 2 types of task(discoverTask, dialTask)
- seeding Ethereum nodes into Kademlia DHT
- create Kademlia DHT
- get Ethereum node’s information from local database(level db) for seeding
- get
seedCount
(default = 30) Ethereum nodes from DB and also hard-coded bootstrap_nodes. - insert
bootstrap_nodes
+DB_nodes
intoDHT
- keep DHT fresh and do bonding process
red-box is a goroutine
- use lookup(random target) process to populate DHT
- validating nodes in DHT with Ping/Pong pakcets(1h)
- keep the old nodes in DHT in DB(5m)
- connection read loop
- create TCP Listener
- create 50 channel for connection and scheduling
- pass the results of handshake to srv.run goroutine’s channel
- add peer to eth.peer
- RLPx handshake
- set both in/outbound connection
- goroutine
- 2 types Task scheduling(discover, dial)
- By its channel, add peer and execute
- discoverTask : kademlia-like lookup
- add nodes into lookupBuf when discoverTask is done
- dialTask : dialing for setupConnection
- kademlia-like lookup
- Get closest(random Target) 16 nodes from DHT
- Among these nodes, if there are first-seen-nodes, doing bonding process and insert into db.
- run when running task is below 16
- MaxDynamicDial(MaxOutboundConn) = ( 1+maxpeer(25) )/2 = 13
- can add staticNode
- leftover dialing count =
needDynDials
- extract 6 nodes(
needDynDials
/2 ) from DHT, and create dialTask - if it still require more nodes, extract 7 nodes from
lookupBuf
, and create dialTask
- Where Inbound connection are actually confirmed
- Inbound connection is no limited
Attacker create a lot of inbound connection requests to the victim in 20 seconds right after the victim boot.
Thus, to prevent all connection from dominated by adversary connections, in Geth 1.9.24v, they set limit of inbound connections. So if attacker send multiple inbound connection requests, there is a limit! And the victim can still connect with normal nodes by outbound connection.