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.
|
|
||
| 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?
| 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.
|
|
||
| * 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?
| * 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?
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