--- title: "Solana SWQoS Endpoint Dokumentation" description: "Überblick und Nutzung des Solana SWQoS (Stake weighted Quality of Service) Endpoints" canonical: "https://erpc.global/de/doc/rpc/swqos-endpoint/" locale: "de" --- # Solana SWQoS Endpoint Dokumentation ## Was ist der SWQoS Endpoint? 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. - ERPC Web Dashboard: https://dashboard.erpc.global/de ## Was ist SWQoS? **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. ## Beziehung zur Priority Fee 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**. ## Verschiebung in der Kostenstruktur 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. - Offizielle Website von elSOL: https://elsol.app/de ## Bandbreitenzuweisung (TPS-Struktur) 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, sobald das Dashboard das Wallet mit dem elSOL-Bestand verifiziert hat. Für dedizierte RPC Nodes ist SWQoS als Option für **+100 €/Monat** verfügbar und weist dem dedizierten Node eine **Staking-Zuteilung von 1.000 SOL** zu. Die Einrichtung und Verifizierung erfolgen über das ERPC Dashboard: https://dashboard.erpc.global ## Verbindung warmhalten (Keep Alive) 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. ## Ping-Endpoint 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. ### Endpoint-Format (HTTPS) ```text https:///ping ``` Ersetzen Sie `` durch die von ERPC bereitgestellte SWQoS-spezifische Domain. ## Anwendungsbeispiel ### Beispiel für periodisches Keep Alive (JavaScript) ```ts async function keepWarm(endpoint: string) { try { await fetch(`${endpoint}/ping`, { method: 'GET' }) } catch { // Ignore failures } } setInterval(() => { keepWarm('https://') }, 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**. ## Hinweise ・`/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**.