search

Zilliqa / zq2

Zilliqa 2.0 code base
Apache License 2.0
6 stars 0 forks source link

Nodes should send direct messages to all nodes, not just committee members #1097

Open JamesHinshelwood opened 6 days ago

JamesHinshelwood commented 6 days ago

Right now get_random_peer can only return a member of the committee.

If I was doing this, I would add another message channel for "send a message to a single node, but I don't care who that node is, just pick a random peer" and handle the selection at the p2p_node layer instead. This also removes the weird non-cryptographic RNG in Consensus.

JamesHinshelwood commented 5 days ago

From @rrw-zilliqa on #1044

It is a hard thing to do - I'd:

  • Don't request blocks directly. Ask a strategy function what to do and have it request blocks on your behalf.
  • Write the strategy function so that it requests block ranges from "the best" current peer.
  • The strategy function maintains a set of ranges which we don't have, but want. If you can, separate these into "blocking - need these now" and "just want these sometime".
  • Strategy function maintains a window and a latency figure for each peer
  • When a block comes in, update the bandwidth and latency for the peer - maybe start with AIMD + fast start.
  • On each tick (fsvo "tick"), fill the windows for random peers .
  • If you really feel bad about it, introduce a NAK. When you have too many requests pending, send some NAKs to close your window to those who are being greedy.

That's it. This is basically TCP, but for blocks. It has the tidy advantage that you incidentally get a map you can display of with whom you are communicating and how well you think they are doing. It has the disadvantage that I just thought of it and it might be utter nonsense :-p