-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
design rationale behind eth #184
Comments
The "data validity" is defined in the sections about blocks and transactions. Data validity is not related to the merkle trie download.
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.
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. |
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:
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?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 theNewBlockHashes
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?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
andNewPooledTxnHashes
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?The text was updated successfully, but these errors were encountered: