Solana SWQoS Endpoint Dokumentation

Der von ERPC bereitgestellte SWQoS Endpoint ist ein leistungsstarker RPC-Dienst, der es Nutzern mit Stake-Verbindungen ermöglicht, Transaktionen über dedizierte Spuren zu senden.
Er ist sowohl für Shared- als auch für dedizierte Pläne verfügbar und ermöglicht eine schnellere und zuverlässigere Transaktionszustellung.

Der Endpoint kann bezogen werden, indem Sie Ihre elSOL-Bestände im ERPC Web Dashboard registrieren.

SWQoS (Stake weighted Quality of Service) ist ein Kommunikationssteuerungsmechanismus, der Validatoren mit Stake-Verbindungen priorisiert.
Leader weisen etwa 80 % der gesamten Bandbreite der Prioritätsspur und 20 % der Nicht-Prioritätsspur zu.

Traffic mit Stake-Verbindungen kann die Prioritätsspur nutzen und gleichzeitig auch über die Nicht-Prioritätsspur gesendet werden. Im Vergleich zu Traffic, der ausschließlich auf der Nicht-Prioritätsspur beruht, ist die effektive Zustellkapazität dadurch deutlich größer.
Diese Steuerung wird vor der Behandlung der Priority Fee angewendet, in der Phase, in der Traffic angenommen und in Richtung Leader geleitet wird. Das bedeutet, dass es sich unmittelbar auf die nachgelagerte Verarbeitungsgeschwindigkeit auswirkt, ob eine Transaktion die Prioritätsspur erreicht.

Die Priority Fee spielt eine wichtige Rolle, aber sie wird angewendet, nachdem eine Transaktion den Leader über SWQoS-Routing erreicht hat.
Wenn eine Transaktion nicht in die SWQoS-Prioritätsspur gelangen kann, wird die Wirksamkeit von Priority Fees eingeschränkt, und die grundlegende Erreichbarkeit lässt sich nur schwer verbessern.
Für einen optimalen Betrieb ist es am effektivsten, die SWQoS-basierte Erreichbarkeit mit passenden Priority-Fee-Einstellungen zu kombinieren.

Bei herkömmlichen Diensten zur Transaktionsübermittlung mussten Nutzer beim Senden von Transaktionen Tips beifügen.
Mit dem SWQoS Endpoint von ERPC sind keine Tips erforderlich. Stattdessen wird der Zugang zu Prioritätsbandbreite durch das Halten von elSOL gewährt.

elSOL ist ein Liquid Staking Token (LST) auf Solana, der durch das Staking von SOL ausgegeben wird.
Sein Wechselkurs gegenüber SOL spiegelt die angesammelten Staking-Belohnungen wider und ist nicht auf ein 1:1-Verhältnis fixiert.

elSOL kann durch den Unstaking-Prozess wieder in SOL umgewandelt werden, wobei die Abrechnung die angesammelten Staking-Belohnungen widerspiegelt.

Das über elSOL gestakte SOL wird an Validatoren delegiert, die mit ERPC verbunden sind.
Mit steigenden elSOL-Beständen wächst die gesamte über ERPC verfügbare SWQoS-Bandbreite.
Durch das Halten von elSOL tragen Nutzer unmittelbar zur Stärkung des Netzwerks bei und erhalten im Gegenzug Zugang zu dedizierten Übertragungsspuren.

Bei shared SWQoS Endpoints erhalten berechtigte Nutzer 1 TPS je 4,2 gehaltene elSOL, abgerundet. Wenn beispielsweise 10 elSOL im verbundenen Wallet gehalten werden, werden 2 TPS zugewiesen.

Die tatsächlich verfügbare TPS wird durch den niedrigeren Wert aus dem Maximalwert des ERPC Plans und der elSOL-basierten Zuweisung bestimmt.

Berechtigte ERPC Shared-Pläne, einschließlich Developer Plan+ und Bundle Plans, können die shared SWQoS Zuweisung nutzen, wenn das Dashboard das Wallet mit dem elSOL Bestand verifiziert.

Für dedicated RPC Nodes ist SWQoS als Option für +100 €/Monat verfügbar und weist dem dedicated Node eine Staking-Zuteilung von 1.000 SOL zu.

Die Einrichtung und Verifizierung erfolgen über das ERPC Dashboard: https://dashboard.erpc.global

Beim Solana SWQoS Endpoint von ERPC können Sie durch das Senden einer GET-Anfrage an /ping die HTTPS-Verbindung zwischen dem Client und dem ERPC SWQoS Endpoint aufrechterhalten.

Beim Übermitteln einer Transaktion benötigt die erste Anfrage eine geringe Zeit für den Aufbau der HTTPS- und TLS-Sitzung.
Indem Sie /ping im Voraus senden und diese Verbindung aktiv halten, können Sie die anfängliche Verbindungslatenz vermeiden und beim Senden der eigentlichen Transaktion sofort in den Übermittlungsprozess einsteigen.

Auch wenn Transaktionen nicht kontinuierlich gesendet werden, ist dieser Ansatz für Setups wirksam, bei denen Transaktionen zu bestimmten Zeitpunkten schnell gesendet werden müssen, und trägt dazu bei, das anfängliche Übermittlungsverhalten zu stabilisieren.

Das Warmhalten erfolgt durch das Senden einer GET-Anfrage an /ping auf dem SWQoS Endpoint.
Diese Anfrage verarbeitet keine Transaktionen und dient ausschließlich der Aufrechterhaltung des Verbindungszustands zwischen dem Client und ERPC.

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

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

Ersetzen Sie <your-swqos-endpoint-domain> durch die von ERPC bereitgestellte SWQoS-spezifische Domain.

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)

Indem Sie /ping in regelmäßigen Abständen senden, können Sie einen Zustand aufrechterhalten, in dem die Transaktionsübermittlung bei Bedarf sofort beginnen kann.

・/ping verbraucht keine TPS und beeinflusst die elSOL-basierten Bandbreitenberechnungen nicht ・Es ist kein Ersatz für die Transaktionsübermittlung ・Es ist eine ergänzende Anfrage, die ausschließlich der Aufrechterhaltung der Verbindung zwischen Client und ERPC dient

Das Design von SWQoS (Stake-basiertes Routing) und Priority Fees bleibt unverändert. Nutzen Sie das Warmhalten als Mechanismus, um die Latenz in dem Moment zu reduzieren, in dem die Transaktionsübermittlung beginnt.