Skip to content
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

Open
oslfmt opened this issue Aug 12, 2021 · 1 comment
Open

design rationale behind eth #184

oslfmt opened this issue Aug 12, 2021 · 1 comment

Comments

@oslfmt
Copy link

oslfmt commented Aug 12, 2021

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
Copy link
Collaborator

fjl commented Aug 16, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants