Documentation de l'endpoint SWQoS Solana

L'endpoint SWQoS fourni par ERPC est un service RPC haute performance qui permet aux utilisateurs disposant de connexions pondérées par le stake d'envoyer des transactions par des voies dédiées.
Il est disponible pour les plans partagés comme pour les plans dédiés, et permet une livraison des transactions plus rapide et plus fiable.

L'endpoint s'obtient en enregistrant vos avoirs en elSOL dans l'ERPC Web Dashboard.

SWQoS (Stake weighted Quality of Service) est un mécanisme de contrôle des communications qui donne la priorité aux validateurs disposant de connexions pondérées par le stake.
Les leaders allouent environ 80 % de la bande passante totale à la voie prioritaire et 20 % à la voie non prioritaire.

Le trafic disposant de connexions pondérées par le stake peut utiliser la voie prioritaire tout en étant envoyé en même temps par la voie non prioritaire. Par conséquent, par rapport au trafic qui dépend uniquement de la voie non prioritaire, la capacité de livraison effective est nettement plus grande.
Ce contrôle s'applique avant le traitement des frais de priorité, au stade où le trafic est accepté et acheminé vers le leader : le fait qu'une transaction atteigne ou non la voie prioritaire influe donc directement sur la vitesse de traitement en aval.

Les frais de priorité jouent un rôle important, mais ils s'appliquent une fois que la transaction a atteint le leader via le routage SWQoS.
Si une transaction ne peut pas entrer dans la voie prioritaire SWQoS, l'efficacité des frais de priorité reste limitée, et il est difficile d'améliorer la capacité de base des transactions à atteindre le leader.
Pour un fonctionnement optimal, le plus efficace est de combiner l'acheminement via SWQoS avec des frais de priorité correctement réglés.

Dans les services classiques d'envoi de transactions, les utilisateurs devaient joindre des tips lors de l'envoi.
Avec l'endpoint SWQoS d'ERPC, les tips ne sont pas nécessaires. L'accès à la bande passante prioritaire est accordé en contrepartie de la détention d'elSOL.

elSOL est un Liquid Staking Token (LST) sur Solana, émis par le staking de SOL.
Son taux de change par rapport à SOL reflète les récompenses de staking accumulées et n'est pas fixé à 1:1.

elSOL peut être reconverti en SOL via le processus d'unstaking, avec un règlement qui reflète les récompenses de staking accumulées.

Le SOL staké via elSOL est délégué à des validateurs connectés à ERPC.
À mesure que les avoirs en elSOL augmentent, la bande passante SWQoS totale disponible sur ERPC s'élargit.
En détenant de l'elSOL, les utilisateurs contribuent directement au renforcement du réseau et obtiennent en retour l'accès à des voies de transmission dédiées.

Pour les endpoints SWQoS partagés, les utilisateurs éligibles reçoivent 1 TPS par tranche de 4,2 elSOL détenus, arrondi à l'inférieur. Par exemple, détenir 10 elSOL dans le wallet connecté donne droit à 2 TPS.

Le TPS réellement disponible correspond à la plus basse de deux valeurs : le maximum du plan ERPC et l'allocation basée sur elSOL.

Les plans partagés ERPC éligibles, y compris Developer Plan+ et les Bundle Plans, peuvent utiliser l'allocation SWQoS partagée une fois que le dashboard a vérifié le wallet qui détient l'elSOL.

Pour les nœuds RPC dédiés, SWQoS est disponible en option à +100 €/mois, qui attribue au nœud dédié une allocation de staking de 1 000 SOL.

La configuration et la vérification se font dans l'ERPC Dashboard : https://dashboard.erpc.global

Avec l'endpoint Solana SWQoS d'ERPC, envoyer une requête GET à /ping vous permet de maintenir la connexion HTTPS entre le client et l'endpoint SWQoS d'ERPC.

Lors de l'envoi d'une transaction, la première requête prend un peu de temps pour établir la session HTTPS et TLS.
En envoyant /ping à l'avance et en gardant cette connexion active, vous pouvez éviter la latence de connexion initiale et passer immédiatement à l'envoi au moment d'envoyer la transaction réelle.

Même si les transactions ne sont pas envoyées en continu, cette approche est efficace pour les configurations qui doivent envoyer des transactions rapidement à des moments précis, et elle aide à stabiliser le comportement du premier envoi.

Le Keep Warming s'effectue en envoyant une requête GET à /ping sur l'endpoint SWQoS.
Cette requête ne traite aucune transaction et sert uniquement à maintenir l'état de la connexion entre le client et ERPC.

https://<your-swqos-endpoint-domain>/ping

https://<your-swqos-endpoint-domain>/ping

Remplacez <your-swqos-endpoint-domain> par le domaine propre à SWQoS fourni par ERPC.

async function keepWarm(endpoint: string) {
  try {
    await fetch(`${endpoint}/ping`, { method: 'GET' })
  } catch {
    // Ignore failures
  }
}

setInterval(() => {
  keepWarm('https://<your-swqos-endpoint-domain>')
}, 30000)

async function keepWarm(endpoint: string) {
  try {
    await fetch(`${endpoint}/ping`, { method: 'GET' })
  } catch {
    // Ignore failures
  }
}

setInterval(() => {
  keepWarm('https://<your-swqos-endpoint-domain>')
}, 30000)

En envoyant /ping à intervalles réguliers, vous pouvez maintenir un état dans lequel l'envoi de transactions peut commencer immédiatement en cas de besoin.

・/ping ne consomme pas de TPS et n'affecte pas le calcul de la bande passante basé sur elSOL ・Il ne remplace pas l'envoi de transactions ・Il s'agit d'une requête complémentaire servant uniquement à maintenir la connexion entre le client et ERPC

La conception de SWQoS (routage fondé sur le stake) et des frais de priorité reste inchangée. Utilisez le Keep Warming comme mécanisme pour réduire la latence au moment où commence l'envoi de transactions.