SIMD 0195 - tpu vote using QUIC #195
Conversation
sakridge
requested review from
sakridge,
jstarry,
ripatel-fd and
lheeger-jump
| transaction transportation. The client and server both uses their validator's | ||
| identity key to sign the certificate which is used to validate the validator's | ||
| identity especially on the server side for the purpose of provding QOS based on | ||
| the client's stakes by checking the client's Pubkey -- stake weighted QOS. |
There was a problem hiding this comment.
Just saying: validator id to vote account association and the stake distribution could change at the Epoch boundary. At Epoch boundary you probably need to accept if the validator has stake in either the old Epoch or the new Epoch.
There was a problem hiding this comment.
Stake info is periodically updated and is eventual consistent. It applies the QOS based on the latest info as it see it. I do not think we need to complicate it to look at potentially two sets of data.
|
|
||
| Once a QUIC connection is established, the client can send vote transaction | ||
| using QUIC UNI streams. In this design, a stream is used to send one single Vote | ||
| transaction. After that the stream is closed. |
There was a problem hiding this comment.
How fast is it to open and close a stream? The QUIC connection will be persistent I assume?
There was a problem hiding this comment.
Open and close stream is light-weight operation. Can be done in one shot: open stream, send and close
| The following QOS mechanisms are employed: | ||
|
|
||
| * Connection Rate Limiting from all clients | ||
| * Connection Rate Limiting from a particular IpAddress |
There was a problem hiding this comment.
What are the limits here? I thought in QUIC we rate limit by pubkey instead of IP? Because others can spoof your IP.
There was a problem hiding this comment.
For stake validation we are validating the pub key. This is only for connection rate limiting before handshake completion
|
|
||
| * Connection Rate Limiting from all clients | ||
| * Connection Rate Limiting from a particular IpAddress | ||
| * Total concurrent connections from all clients -- this is set to 2500 |
There was a problem hiding this comment.
Is it dangerous to increase this limit? What if we suddenly have >2500 clients?
There was a problem hiding this comment.
This is up to the implementation. And we have plan to make this configurable. 2500 is more than enough for votes in mb
| * Total concurrent connections from all clients -- this is set to 2500 | ||
| * Max concurrent connections from a client Pubkey -- this is set to 1 for votes. | ||
| * Max concurrent streams per connection -- this is allocated based on the ratio | ||
| of the validator's stake over the total stakes of the network. |
There was a problem hiding this comment.
What is the reasoning here? Why does higher-staked validator need more concurrent streams per connection?
There was a problem hiding this comment.
Give them more bandwidth as reward and ensure they have better chance landing their votes?
lijunwangs
changed the title
| The following QOS mechanisms are employed: | ||
|
|
||
| * Connection Rate Limiting from all clients | ||
| * Connection Rate Limiting from a particular IpAddress | ||
| * Total concurrent connections from all clients -- this is set to 2500 | ||
| * Max concurrent connections from a client Pubkey -- this is set to 1 for votes. | ||
| * Max concurrent streams per connection -- this is allocated based on the ratio | ||
| of the validator's stake over the total stakes of the network. | ||
| * Maximum of vote transactions per unit time which is also stake weighted |
There was a problem hiding this comment.
Firedancer won't enforce any of these limits server-side.
These should more like implementation-specific behavior, so I suggest removing them from the SIMD.
Added SIMD for tpu vote using QUIC