Supernodes #91
Supernodes #91
Conversation
spalladino
left a comment
spalladino
left a comment
There was a problem hiding this comment.
LGTM. Two things I think are worth reviewing, either in this doc or another one:
- What are the expected bandwidth requirements for supernodes, depending on TPS and number of supported peers?
- Do we want to limit the type of messages handled by supernodes? For example, do we want supernodes to only gossip (or serve via req/resp) txs included in blocks but not pending txs, to ensure that the bandwidth prioritises messages required for consensus? Feels like an extra complexity, but maybe there are some low-hanging fruits like disabling the tx reqresp subprotocol in supernodes in favor of only keeping the
block-txssubprotocol.
| } | ||
| ``` | ||
|
|
||
| Validators should only respond to auth requests from known Supernodes if they aish to keep their identity as a validator hidden. |
There was a problem hiding this comment.
| Validators should only respond to auth requests from known Supernodes if they aish to keep their identity as a validator hidden. | |
| Validators should only respond to auth requests from known Supernodes if they wish to keep their identity as a validator hidden. |
|
|
||
| 5. Maintaining Supernode Connections | ||
|
|
||
| Connection managment between nodes and supernodes will be largely the same as existing connection management. The only difference being that on disconnection from a supernode, the supernode's PeerId will be removed from the `directPeers` collection within Gossipsub. |
There was a problem hiding this comment.
Does this mean that if a supernode goes down temporarily, a node will not attempt to establish a direct connection to it again?
There was a problem hiding this comment.
Nodes connecting to supernodes would attempt to maintain their target connections. So if my connection to a supernode breaks, I may retry for a bit perhaps but after sometime I would try a different one instead. Peer Ids can be added/removed from directPeers as and when connections are created/destroyed.
|
|
||
| As supernodes aren't discovered in the usual way, we will implement slightly different selection and connection logic. Nodes can configure a `TARGET_NUM_SUPERNODES`, defaulting to e.g. 2. Nodes that do so will continually attempt to maintain connections to `TARGET_NUM_SUPERNODES` randomly selected supernodes from the configuration. | ||
|
|
||
| Upon successful connection, the supernode may issue an authentication handshake request. This request is a superset of the status handshake request including an additional randomly generated field value challenge. Supernodes shouldn't issue this request if the connection is from another supernode. |
There was a problem hiding this comment.
may issue an authentication handshake request
Do we plan on having supernodes that do NOT require an auth handshake request? If so, how do non-validator nodes figure out which supernodes they should try to connect to? Trial and error, or should we have separate sections in the network config for authed and non-authed supernodes?
There was a problem hiding this comment.
I put 'may' here because ultimately, it's not us that would be running the supernode and whoever is could decide they don't want to limit their connections just to validators. But maybe this shouldn't be an option. Running with the supernode setting means you always ask for authentication.
The primary purpose of supernodes is really to give validators a high QOS overlay mesh.
Yes, we will definitely need to try and quantify what's a reasonable bandwidth expectation and how many peers that could serve.
|
No description provided.