search

ethereum / devp2p

Ethereum peer-to-peer networking specifications
979 stars 275 forks source link

design rationale behind eth #184

Open oslfmt opened 3 years ago

oslfmt commented 3 years ago

I have a few general questions and questions about the design rationale behind the protocol, and why certain things are done the way they are:

  1. In state/fast sync, it says that only data validity of blocks are verified, and GetNodeData is used to incrementally request Merkle tree nodes until the whole tree is synced. What exactly does "data validity" mean, and why does requesting the Merkle tree nodes have to do with it? Is this essentially having the nodes recreate the state trees?

  2. In block propagation, nodes first propagate the full block via NewBlock to a small fraction of connected peers. This is only after the PoW validity is verified, not the bodies yet. The node then does body verification by executing txns, and finally then sends the NewBlockHashes message to all peers it didn't notify earlier. A few questions here: if only the PoW is verified, doesn't this mean the body may be invalid, and thus nodes are propagating invalid blocks and thus may be dropped as peers? If this is not an issue, why do we do this, instead of just verifying the entire block first before sending it? Is it because just verifying PoW is faster to propagate block while still offering some security, ie, we are making a security vs. speed tradeoff here?

  3. Finally, in transaction exchange, it says when a new connection is made, transaction pools are synced. But it also says when new transactions appear in a client's pool, it propagates them to the rest of the network using Transactions and NewPooledTxnHashes messages. I don't have a full understanding of RLPx yet, but in general I'm confused as to what a connection is exactly. I understand RLPx is built on top of TCP, and don't TCP connections generate extra overhead and time? So if we want to propagate transactions across the network as fast as possible, and as I understand nodes have to make connections first, won't this introduce a lot of delay? And if these connections instead are long-lived, how long is that?

fjl commented 3 years ago

What exactly does "data validity" mean, and why does requesting the Merkle tree nodes have to do with it?

The "data validity" is defined in the sections about blocks and transactions. Data validity is not related to the merkle trie download.

Is it because just verifying PoW is faster to propagate block while still offering some security, ie, we are making a security vs. speed tradeoff here?

Yes. Validating the PoW is very quick, and coming up with a valid PoW seal is very expensive on mainnet, so it's a good tradeoff. If the block turns out invalid, the node will not accept it.

and don't TCP connections generate extra overhead and time? So if we want to propagate transactions across the network as fast as possible, and as I understand nodes have to make connections first, won't this introduce a lot of delay?

The "eth" network is an unstructured graph of TCP connections between nodes. Basically, it is assumed that nodes will continuously establish connections and maintain them. The connections are "long-lived", i.e. it's not like HTTP with one connection per request. Instead, once a connection is created, it can be maintained until either side decides to end the connection. There is no need to create a connection specifically for relaying a single transaction.