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

implement "quic-forward-proxy" service that allows n inbound senders to use(share) staked identity #142

Closed
grooviegermanikus opened this issue May 30, 2023 · 4 comments
Milestone

Comments

@grooviegermanikus
Copy link
Collaborator

grooviegermanikus commented May 30, 2023

Problem:

  • TPU has complex logic to assign connection capacity to TPU clients; this considers stake vs unstaked connections, per peer/per node limits, QUIC stream limits
  • staking nodes is a potential security problem; should be minimized
  • lite-rpc nodes cannot be stateless/scaled with stake assigned

Proposed solution overview:

Architektur overview:

  • many TPUs (solana validators)
  • one quic-forward-proxy
  • many clients
  • clients connect to proxy and proxy connects to TPU

Proposed solution details:

  • Implement a QUIC proxy service (independently deployable network service).
  • QUIC proxy receivers transactions from its clients and forwards them to TPU via QUIC.
  • dedicated protocol needs to be used between clients and the Quic Proxy.
  • Service must accept multiple inbound QUIC connections.
  • Clients of the proxy service might be lite-rpc instances, lite-rpc-library users or other components (e.g. bots).
  • Proxy Service must use its assigned stake identity to TLS-sign the connection to the TPU target node.
  • Senders must specify the TPU target node (based on leader schedule known by the client; usually be using lite-rpc-library).
  • Must allow for transactions.
  • expect that one instance of the service is running (or at least needs to appear as single IP-Address/peer to the TPU)
  • the quic-proxy must be powerful enough to take all ingress traffic
  • No streaming is required. Use quic multiplexing to connect to TPU.
  • authentication: QUIC certificate whitelisting / root-CA pinning (quic-forward-proxy: authenticate clients #167)

Similar approaches:

note: there is a similar/alternative approach for client-TPU-Interaction using reverse-proxy model,
"node must advertise to gossip for inbound traffic that is designated for leader"

@grooviegermanikus
Copy link
Collaborator Author

use Rust, might run in kernel

@grooviegermanikus
Copy link
Collaborator Author

See solana code:
quic.rs, compute_max_allowed_uni_streams: l.222
"max_connections_per_peer"

@grooviegermanikus
Copy link
Collaborator Author

POC on lite-rpc branch

@grooviegermanikus
Copy link
Collaborator Author

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

3 participants