I can only answer for libp2p coming from the IPFS project (and not devp2p coming from Ethereum).
libp2p is a modular P2P networking stack used to connect to other peers, finding and transferring content. You can see it as a collection of protocol that can use different routing, discovery and transports, depending on your needs.
It began its development ...
The peer discovery algorithm is based on the kademlia protocol.
A standalone implementation can be found here.
A simplified model of how the p2p algorithm works is the following:
you have nodes that are assumed to be always available/online (in
Ethereum they are called bootstrap nodes)
bootstrap nodes maintain a list of all nodes that connected to ...
I did the math to show the aprox tx/s:
The block gas limit is 7,999,992
Transaction costs 21,000 gas (let's assume nothing else is attached)
That's ~380 transactions per block
With a block time of around 15.03 seconds. As https://ethstats.net/ shows.
This gives us aproximately: 25.346 tx/s.
At the end of your question, you have mentioned some possible ...
LIBP2P is a protocol implementation toolset or library that allows you to build software for different P2P networks and scenarios.
DEVP2P and RLPx are presented in the Ethereum documentation as something separate, but in fact:
They are the same thing if you are talking about a protocol
They are different things if you are talking about message formats
You can see the connected peers by typing admin.peers in the Geth console. The maximum number of peers is set using the -maxpeers n flag in Geth.
There is a discovery process based on Kademlia for finding nodes, then a handshaking process by which they determine which devp2p protocols they support (Eth, Bzz, Shh). The P2P layer monitors each node's quality ...
Ethereum uses DevP2P, which is a general protocol of discovery and connection of nodes, with an ethereum subprotocol defined on top of it (as opposed to the subprotocol of swarm, whisper, etc).
You can read the following links to get a deeper view:
I wrote this on the gitter.im channel, so here it is again anyway. Caveat is I have not looked at recent geth code for this, so there may be subtle discrepancies with actuality.
A key paragraph is this "Message IDs are assumed to be compact from ID 0x10 onwards (0x00-0x10 is reserved for ÐΞVp2p messages) and given to each shared (equal-version, equal name) ...
Only a partial answer for the first couple of sub-questions...
How many nodes do we connect to?
The maximum number is set to 25 by default, but can be configured using the --maxpeers flag on the command line. This limit is flexible when taking into account "trusted" nodes. (See below.)
The finer detail is that we can also set the combined total of both ...
Ð is a letter from Old English, pronounced "eth".
So "Ðapp" could actually be pronounced "eth-app", though I imagine most people pronounce the Ð as a hard "d" (for dog).
Ξ is the upper-case Greek letter, Xi. I don't know why this was chosen (someone else might).
You're missing the mining process. You should really explore it for a better understanding.
Transactions will be sent to one of the nodes which will broadcast the transaction to the other(s). Concurrency and order isn't important because although the transactions will eventually be known to all nodes, none of the nodes will do any transaction processing at ...
I had to dig around to find the hint that I was pretty sure existed :-)
It's in the Design Rationale document, under Compression algorithm.
The wire protocol and the database both use a custom compression
algorithm to store data. The algorithm can best be described as
run-length-encoding zeroes and leaving other values as they are, with
You do everything right with init. As far as I understand you updated geth to last release, where hardware wallets support was added. So it requires libusb to be installed in your system. You should install it.
Q: is UDP officially used for node discovery and then TCP for communication?
You can see the 30301 UDP discovery port in the enode URL format (from enode url format):
Q: if so where is this node discovery protocol documented?
At https://github.com/ethereum/devp2p/blob/master/rlpx.md .
The RLPx protocol suite consists of at least two protocols:
The Kademlia like discovery protocol, that involves UDP packets that are simply signed by the nodes and not encrypted
The RLPx/devp2p protocol, that involves encrypted TCP packets. This protocol requires a two-phase handshake. In the first phase the peers exchange the secret used to encrypt the ...
Being connected to 35 peers is usually more than enough. What are you trying to achieve that makes you want to be connected to more nodes?
I assume you are using a computer at home which usually is connected via a router to the internet, maybe even behind a firewall that limits possible connections further. This might limit the number of nodes that you are ...
The Ethereum Foundation runs bootnodes and the clients have the enode URIs hardcoded into the clients. These nodes are used for initial discovery and are generally disconnected from once someone has enough nodes. You can read more about the general wire protocol, called DEVp2p here.
What are the exact rules applied by Geth, Parity, and/or other clients to determine a peer's reputation?
The exact answer to this is the source code for each client. To answer this question I've only looked at Geth's source, I can't speak to what Parity does.
In particular, is being honest sufficient to get a good or even optimal reputation or is ...
Does someone know if there is any documentation on encryption in the inter-node protocol?
You might have already found these, but here are few sources I've used in the past:
https://github.com/ethereum/devp2p/blob/master/rlpx.md (The RLPx Transport Protocol)
https://github.com/ethereum/devp2p/blob/master/devp2p.md (devp2p Application Protocol)
devp2p is the older network wire protocol, for propagating blocks and other low-level functionality between Ethereum nodes. It was designed specifically for Ethereum from scratch, in isolation from other distributed systems and open source projects.
libp2p is the wire protocol used by IPFS, which in many ways supplies the distributed file storage that ...
The Server.go(p2p.Server) is responsible for synchronize data from others p2p node(running P2P networking layer).
The Node.go is responsible for all thing of an Ethereum node, ie: sync data, RPC server, etc.
As you see, Node.go has a property is p2p.Server.
The Ethereum blockchain utilizes a Proof-of-Work (PoW) variant in an implementation called Ethash. PoW does not involve reputation. The reputation you're reading about likely refers to "off-chain" reputation e.g. public scorn or 2nd layer reputation engines that track and award/punish based on some calculated measure of miner reputation (e.g. bonding curves ...
In case you don't know the role of DEVp2p and RLPx :
Though TCP provides a connection-oriented medium, ÐΞVp2p nodes communicate in terms of packets. RLPx provides facilities to send and receive packets
How nodes know each others?
I tried to catch articles to create own private network based on PoA. The flow after I had created nodes was:
Nodes will be in ...
Whisper messages are broadcasts to all nodes, but not all the nodes are necessarily configured to act on them. Have you read the white paper -
It's not quite the same thing in that it uses a different form of abstraction, but there's a Consensys tool called EthOn that provides a way to visualise data flows within Ethereum in an ontological way, using Web Ontology Language (OWL).
Example illustrations can be found at this link.
It was first described in this Medium post.
The accepted answer is not correct. The bootnodes are unreliable. A node can get blacklisted from the bootnodes and the bootnodes are sometimes unavailable without any apparent reason.
The Ethereum network carries forward on its own inertia because peers maintain a history of seed candidates based on past experience. Completely new nodes must join the ...