Stake-Weighted Quality of Service: Alles, was du wissen musst

Einführung

Solana steht als Netzwerk mit hohem Durchsatz und niedriger Latenz an der Spitze der Blockchain-Technologie und verschiebt die Grenzen dessen, was ein dezentrales Netzwerk leisten kann. Das bringt jedoch erhebliche Herausforderungen mit sich. Ein entscheidender Moment in der Entwicklung von Solana war der Ausfall am 30. April 2022. Er verdeutlichte, dass robustere Mechanismen nötig sind, um große Transaktionsvolumen zu bewältigen und die Netzwerkleistung unter hoher Last aufrechtzuerhalten.

Stake-Weighted Quality of Service (SWQoS) entstand als Reaktion auf dieses Ereignis. Dieser Mechanismus priorisiert Netzwerkverkehr anhand des Stakes der Validatoren. So können Validatoren mit mehr Stake Transaktionen mit höherer Priorität senden. SWQoS soll verhindern, dass Validatoren mit wenig Stake das Netzwerk überlasten, und verbessert damit die Widerstandsfähigkeit und Effizienz von Solana.

Dieser Artikel erklärt SWQoS, das Transaktionsverarbeitungsmodell von Solana und den Einfluss von SWQoS darauf. Außerdem behandelt er Staked Connections, ihre Einrichtung und den Unterschied zwischen SWQoS und Priority Fees. Hinzu kommen künftige Auswirkungen, insbesondere die wachsende Bedeutung von Validatoren und Liquid Staking Tokens (LSTs), Einstiegshürden und die Vertrauensannahmen dieses Systems.

Dieser Artikel setzt Kenntnisse über das Programmiermodell von Solana und QUIC voraus. Falls du mit diesen Themen nicht vertraut bist, solltest du zuerst die folgenden Artikel lesen:

• Das Solana-Programmiermodell: Eine Einführung in die Entwicklung auf Solana
• Spam schnell mit QUIC eindämmen: Alles, was du über Solana und QUIC wissen musst

Wo nötig, liefern wir dennoch den entsprechenden Kontext.

Was ist Stake-Weighted Quality of Service?

Stake-Weighted Quality of Service (SWQoS) ist ein Mechanismus, der Netzwerkverkehr anhand des Stakes der Validatoren priorisiert. So können Validatoren mit mehr Stake Transaktionen effektiver senden und erhalten eine höhere Servicequalität.

Da Solana ein Proof-of-Stake-Netzwerk ist, liegt es nahe, die Stake-Gewichtung auf die Transaktionsleistung auszuweiten. Vereinfacht gesagt nutzt Solana Stake – also bei einem Validator gebundene Mittel zur Absicherung des Netzwerks – als Signal dafür, wie vertrauenswürdig ein Validator ist. Je mehr Stake ein Validator hält, desto stärker ist sein eigenes Interesse an der Sicherheit und Zuverlässigkeit des Netzwerks. Zudem ist Quality of Service ein Netzwerkkonzept, bei dem bestimmte Pakete priorisiert werden, um ihre zuverlässige Übertragung zu gewährleisten. Solana bietet Validatoren mit Stake daher eine zuverlässigere Transaktionsübertragung, indem es ihre Transaktionen über priorisierte Verbindungen leitet.

SWQoS soll vor allem verhindern, dass Validatoren mit wenig Stake das Netzwerk mit Transaktionen überlasten und dadurch Transaktionen von hochwertigeren Validatoren oder solchen mit mehr Stake verdrängen. Hält ein Validator beispielsweise 5 % des gesamten Stakes, kann er 5 % aller Pakete an den Leader senden. SWQoS lässt sich als Mechanismus zur Sybil-Resistenz betrachten, der es böswilligen Akteuren erschwert, das Netzwerk mit „minderwertigen“ Transaktionen zu fluten.

Stell dir vor, du bist bei einer beliebten Veranstaltung wie einem Konzert oder in einem Freizeitpark, für die es nur eine begrenzte Anzahl an Tickets gibt. An den normalen Ticketschaltern kann sich jeder anstellen, doch die Schlangen werden schnell lang und langsam. Daneben gibt es VIP-Schlangen für Kunden, die mehr bezahlen. Sie sind deutlich kürzer und schneller, weil nur Personen Zugang erhalten, die bestimmte Kriterien erfüllen, etwa eine besondere Mitgliedschaft. Außerdem wird einer bestimmten Anzahl von ihnen gleichzeitig der Eintritt garantiert. Im Kontext von Solana gleicht SWQoS diesen VIP-Schlangen: Der Zugang hängt davon ab, wie viel Stake ein Validator hält. Je mehr Stake du hast, desto mehr VIP-Zugang – also priorisierte Verbindungen – erhältst du. Dadurch werden Tickets beziehungsweise Transaktionen schneller und zuverlässiger verarbeitet.

Wie funktioniert das in der Praxis? Zunächst musst du verstehen, wie Solana Transaktionen verarbeitet.

Wie Solana Transaktionen verarbeitet

Die Transaction Processing Unit (TPU) von Solana verarbeitet Transaktionen effizient und führt sie aus. Die Verarbeitung erfolgt in mehreren klar getrennten Phasen. So werden Transaktionen validiert, ausgeführt und im Netzwerk verbreitet. Diese Phasen sind die Fetch Stage, SigVerify Stage, Banking Stage, der Proof of History (PoH) Service und die Broadcast Stage.

Die Fetch Stage

Die Fetch Stage empfängt eingehende Transaktionen von Clients über das Netzwerk. Sie bündelt Eingaben von einem UDP-Socket und ordnet sie drei wichtigen Sockets zu:

• tpu: Für reguläre Transaktionen wie Token-Übertragungen, NFT-Mints und Programminteraktionen
• tpu_vote: Für Vote-Transaktionen
• tpu_forwards: Leitet nicht verarbeitete Pakete an den nächsten Leader weiter, wenn der aktuelle Leader nicht alle Transaktionen verarbeiten kann.

Diese Sockets werden in Gossip erstellt, in der Struktur ContactInfo gespeichert und mit dem jeweiligen Socket gekennzeichnet.

Die Fetch Stage führt gleichzeitig empfangene Pakete zusammen. Das reduziert die Zahl der einzelnen Verarbeitungsvorgänge und erhöht den Durchsatz. Empfangene weitergeleitete Pakete markiert sie mit einem FORWARDED-Flag, damit nachfolgende Phasen sie entsprechend erkennen. Ist der Node nicht der aktuelle Leader, verwirft er diese weitergeleiteten Pakete, um unnötige Verarbeitung zu vermeiden. Ist der Node jedoch der Leader, berücksichtigt und verarbeitet er sie.

Die Fetch Stage erstellt unbegrenzte Channels wie packet_sender und packet_receiver, um Transaktionen an die nächste Phase, die SigVerify Stage, zu übergeben. Diese Channels entkoppeln die TPU-Phasen, sodass sie parallel arbeiten können, ohne sich gegenseitig zu blockieren. Die Funktion unbounded erstellt einen Channel mit unbegrenzter Kapazität. So gehen bei einem Überlauf keine Pakete verloren. 

Transaktionen werden in Gruppen von 128 Paketen gebündelt und anschließend an die SigVerify Stage weitergeleitet. Diese Bündelung macht die Verarbeitung effizienter und reduziert den Aufwand für einzelne Pakete. 

Die Fetch Stage arbeitet in mehreren Threads, um einen hohen Durchsatz zu bewältigen. Jeder Thread übernimmt eine bestimmte Aufgabe, etwa Pakete zu empfangen, Batches zu verarbeiten oder Transaktionen weiterzuleiten. Für jeden Socket-Typ – also tpu, tpu_vote und tpu_forwards – wird mit der Funktion streamer::receiver ein Thread erstellt. Jeder Thread überwacht den ihm zugewiesenen Socket, verarbeitet eingehende Pakete und sendet sie über den passenden Channel.

Indem die Fetch Stage eingehende Transaktionen effizient verwaltet und kategorisiert, schafft sie die Grundlage für alle folgenden Verarbeitungsphasen in der TPU von Solana.

Die SigVerify Stage

Die SigVerify Stage ist die zweite Phase der Transaktionsverarbeitung von Solana. Sie ist entscheidend, um Integrität und Authentizität der Transaktionen sicherzustellen. 

In dieser Phase empfängt die TPU gebündelte Transaktionen aus der Fetch Stage über unbegrenzte Channels. Die Hauptaufgabe besteht darin, Transaktionssignaturen mit dem Ed25519-Signaturverfahren zu prüfen. Diese kryptografische Validierung bestätigt, dass der rechtmäßige Eigentümer der beteiligten Accounts die Transaktion signiert hat.

Die SigVerify Stage ist auf hohe Leistung ausgelegt. Sie nutzt die parallelen Verarbeitungsfunktionen moderner CPUs und GPUs, um Signaturen zu prüfen. Standardmäßig übernimmt die CPU die gesamte Verarbeitung. Aufgrund der Parallelisierung beschleunigt GPU-Offloading den Vorgang jedoch erheblich, wenn Performance-Bibliotheken verfügbar sind.

Der Prozess beginnt mit der Funktion new. Sie initialisiert die SigVerify Stage und richtet die nötigen Receiver-Channels für Pakete aus der Fetch Stage ein. Die Funktion verifier empfängt Batches und prüft Signaturen. Sie entfernt Duplikate, verwirft überschüssige Pakete und prüft die verbleibenden Pakete. Zur Signaturprüfung verwendet die Funktion die Methode ed25519_verify. Bei hohem Transaktionsvolumen kommt Load Shedding zum Einsatz. Dabei verwirft die SigVerify Stage überschüssige Pakete. Dazu gruppiert sie Pakete nach ihrer Quell-IP-Adresse und legt pro Adresse eine maximale Zahl zu verarbeitender Pakete fest.

Transaktionen mit ungültigen Signaturen werden markiert und verworfen. So gelangen nur gültige Transaktionen weiter und betrügerische oder fehlerhafte Transaktionen erreichen nicht die nächste Phase.

Nach der Signaturprüfung werden gültige Transaktionen über weitere unbegrenzte Channels an die nächste Phase, die Banking Stage, übergeben. Dadurch bleiben die Phasen entkoppelt und können parallel arbeiten. Auch diese Phase läuft in mehreren Threads. Jeder Thread verarbeitet eine Teilmenge der Transaktionen, prüft Signaturen, entfernt Duplikate und führt Load Shedding durch.

Die Banking Stage

Die Banking Stage ist die dritte Phase der Transaktionsverarbeitung von Solana. Sie ist entscheidend, weil Transaktionen hier ausgeführt und auf den aktuellen Ledger-Status angewendet werden. Die Banking Stage nutzt die einzigartige Sealevel-Runtime von Solana, um Transaktionen parallel und mit hohem Durchsatz zu verarbeiten.

Die Banking Stage verfügt über sechs Threads: Zwei verarbeiten Vote-Transaktionen aus der TPU oder aus Gossip, vier verarbeiten andere Transaktionen. Jeder Thread arbeitet unabhängig und empfängt Pakete aus einem gemeinsamen Channel – dies ändert sich nach Version 1.18 –, an den SigVerify Pakete in Batches sendet. Jeder Thread entnimmt diesem gemeinsamen Channel Transaktionen und speichert sie in einem lokalen Puffer. Der lokale Puffer dient als Priority Queue und wird dynamisch aktualisiert, um Änderungen am Transaktionsstatus und an den Netzwerkanforderungen in Echtzeit abzubilden. 

Wie diese Transaktionen behandelt werden, hängt davon ab, ob der Validator im Leader-Zeitplan steht. Steht der Validator nicht kurz davor, Leader zu werden, leitet er die Pakete an den nächsten Leader weiter und verwirft sie anschließend. Nähert er sich seinem Einsatz – etwa 20 Slots vorher –, leitet er Pakete weiterhin weiter, behält sie aber für den Fall, dass die nächsten Leader sie nicht verarbeiten. Zwei Slots vor seinem Einsatz als Leader hält er die Pakete zurück, damit er sie verarbeitet, sobald er Leader wird.

Während der Blockproduktion verarbeitet jeder Thread die obersten 128 Transaktionen aus seiner lokalen Queue. Der Ablauf umfasst Schritte wie Sperren, Prüfen, Laden, Ausführen, Aufzeichnen, Committen und Entsperren. 

Die Banking Stage bündelt Transaktionen mit einem Multi-Iterator-Ansatz. Dadurch lässt sich ein Datensatz gleichzeitig durchlaufen und Transaktionen können zu konfliktfreien Batches gruppiert werden. Zunächst werden die Transaktionen in einen prioritätsbasierten Vektor serialisiert. Anschließend platziert der Multi-Iterator Iteratoren an Stellen, an denen Transaktionen nicht miteinander in Konflikt stehen, und erstellt Batches mit 128 Transaktionen. Transaktionen mit Konflikten werden übersprungen und nach Behebung des Konflikts in spätere Batches aufgenommen. Sobald ein Batch gebildet ist, werden die Transaktionen ausgeführt. Erfolgreiche Transaktionen werden im Proof of History Service aufgezeichnet und über Turbine im Netzwerk verbreitet.

Proof of History (PoH) Service

Der Proof of History (PoH) Service ist ein grundlegender Bestandteil der Transaktionsverarbeitung von Solana. Er bietet eine überprüfbare Methode, um Zeit und Reihenfolge von Ereignissen im Netzwerk nachzuverfolgen. Dadurch lassen sich Transaktionen effizient und sicher anordnen. Über eine Hash-Kette erzeugt er eine kryptografische Sequenz, die als Zeitstempel für Transaktionen dient. Diese fortlaufende Kette von Hashes erstellt einen historischen Datensatz, der den Zeitverlauf zwischen Ereignissen belegt.

Der PoH Service stellt sicher, dass sich alle Netzwerkteilnehmer auf die Reihenfolge der Transaktionen einigen können, ohne eine zentrale Zeitinstanz zu benötigen. Außerdem hilft er dabei, Validatoren im gesamten Netzwerk zu synchronisieren. Er unterstützt die Leader-Wahl von Solana mit einem zuverlässigen Zeitstempel, der bestimmt, wann ein Validator Leader werden und den nächsten Block erzeugen soll.

Der PoH Service initialisiert zunächst einen Seed-Wert, aus dem eine Folge von Hashes entsteht. Eingehende Transaktionen werden mit dem aktuellen Hash aus der PoH-Sequenz versehen und erhalten so einen eindeutigen Zeitstempel. Anschließend prüfen Validatoren die Hash-Sequenz, um Reihenfolge und Zeitpunkt der Transaktionen zu bestätigen.

Mehr über Proof of History erfährst du in unserem Artikel Proof of History, Proof of Stake und Proof of Work erklärt. Falls Kryptografie für dich wie eine Fremdsprache klingt, empfehlen wir außerdem unseren Artikel Grundlagen kryptografischer Werkzeuge – Hash-Funktionen und Merkle-Bäume erklärt.

Die Broadcast Stage

Die Broadcast Stage ist die letzte Phase der Transaktionsverarbeitung von Solana. Sie verteilt validierte und bestätigte Transaktionen an den Rest des Netzwerks.

Nachdem Transaktionen in der Banking Stage verarbeitet und committet wurden, werden sie zu Einträgen zusammengefasst. Diese Einträge werden anschließend in Datenstrukturen namens Shreds verpackt. Die Broadcast Stage serialisiert und signiert diese Shreds und erzeugt Erasure Codes, um Datenintegrität und Wiederherstellung zu verbessern. Über einen strukturierten, baumartigen Verteilungsprozess namens Turbine werden die Shreds an Peers gesendet. Dieser Prozess verteilt Daten effizient und redundant. Mithilfe von Erasure Coding können Validatoren fehlende oder beschädigte Daten rekonstruieren.

Eine ausführlichere Erklärung von Turbine findest du in unserem Artikel Turbine: Blockverteilung auf Solana.

Der Lebenszyklus einer Transaktion mit SWQoS

Anders als andere Blockchains besitzt Solana keinen Mempool, in dem Transaktionen vor der Verarbeitung warten. Stattdessen werden Transaktionen direkt an den aktuellen Leader geleitet und von dessen TPU verarbeitet. Nutzer erstellen Transaktionen direkt oder indirekt mit einer Wallet oder Anwendung und übermitteln sie über die JSON RPC API an RPC-Nodes. Diese Nodes vermitteln zwischen Nutzern und den Validatoren von Solana. Wichtig ist: Sie sollten keinen Stake im Netzwerk besitzen. RPC-Nodes haben also keinen Stake, stimmen nicht ab und nehmen daher nicht am Konsens teil.

Verbindungen zu einem Leader werden heute über QUIC hergestellt. QUIC wurde für die Ports eingeführt, über die Nutzertransaktionen in die TPU von Solana gelangen, und ersetzt dort UDP. Da QUIC einen Handshake erfordert, lässt sich der Datenverkehr einzelner Akteure begrenzen. So kann sich das Netzwerk auf echte Transaktionen konzentrieren und Spam herausfiltern. Natürlich war genau das die Absicht hinter der Einführung von QUIC. Wie effektiv QUIC aktuell ist, diskutieren wir in diesem Artikel nicht. Entscheidend ist, dass Verbindungen zum Leader über QUIC hergestellt werden.

Es gibt zwei Arten von Verbindungen:

• 500 offene Verbindungen, auf die jeder RPC-Node zugreifen kann
• 2000 Stake-gewichtete Verbindungen, auf die nur Validatoren mit Stake zugreifen können. Validatoren erhalten einen proportionalen Anteil dieser Verbindungen, der von ihrem Stake abhängt

Damit ein RPC eine Transaktion effektiv weiterleiten kann, muss er mit einem Validator mit Stake gekoppelt sein. Da RPCs selbst keinen Stake im Netzwerk besitzen, müssen Validatoren ihren Stake virtuell erweitern. Mit dem Flag --staked-nodes-overrides können Validatoren einen Teil ihrer Staked Connections bestimmten RPC-Nodes zuweisen. 

Ein Validator muss mit --staked-nodes-overrides flag den Pfad zu einer YAML-Datei angeben, um seine Stake-gewichteten Verbindungen zu konfigurieren. Die YAML-Datei enthält Zuordnungen in folgender Form:

staked_map_id:
	<pubkey_of_RPC>: 80000000000000000

Für jeden öffentlichen Schlüssel einer bestimmten RPC-Identität ist ein Wert in Lamports erforderlich. Dieser Wert gibt an, welches Stake-Gewicht du der RPC-Identität zuweisen möchtest. Gibst du beispielsweise eine Million SOL an, weist du ihr eine Million SOL geteilt durch den gesamten aktiven Stake zu. Im Grunde gibst du dem RPC-Node Staked Connections, als wäre er ein Validator mit entsprechend viel Stake im Netzwerk. Du sagst damit: „Behandle diese RPC-Identität in meiner lokalen Sicht so, als hätte sie beim Austausch mit meinem Validator x Stake.“ Für diese Einrichtung muss der Validator nicht neu gestartet werden. Änderungen an der Datei lassen sich im laufenden Betrieb vornehmen und neu laden.

Außerdem unterstützt der Jito-Relayer das Flag für Staked-Node-Overrides. Für optimale Leistung sollte der Relayer auf demselben Rechner wie der Staked Node ausgeführt werden.

Um diese Staked Connections zu nutzen, müssen RPC-Betreiber das Flag --rpc-send-transaction-tpu-peer verwenden. Dafür sind IP-Adresse und TPU-Port des Validators mit Stake erforderlich. Wie in Gossip ersichtlich, beginnt der TPU-Port üblicherweise drei Ports nach dem Anfang des dynamischen Portbereichs. Bei Jito wird der Datenverkehr an den vom Betreiber ausgeführten Relayer geleitet, da öffentliche Jito-Relayer nicht verwendet werden können. RPC-Betreiber sollten ihre Logs auf Einträge wie solana_quic_client und warm prüfen, um die Verbindung zu verifizieren. Für diese Einrichtung muss auf dem RPC-Node ein Agave-Client ab Version v1.17.28 laufen, da erst diese Version das erforderliche Flag unterstützt.

Insgesamt bleibt der Lebenszyklus einer Transaktion mit SWQoS weitgehend derselbe wie bei einer regulären Transaktion. Nutzer erstellen Transaktionen, übermitteln sie über RPC-Nodes und senden sie dann an den Leader. Ist ein RPC-Node jedoch mit einem Validator mit Stake gekoppelt und verwendet das Flag --rpc-send-transaction-tpu-peer, werden Transaktionen über Staked Connections gesendet. Zusammengefasst:

• Transaktionserstellung: Ein Nutzer erstellt eine Transaktion mit seiner Wallet, einer Anwendung oder programmatisch 
• Übermittlung an einen RPC-Node: Die Transaktion wird über die JSON RPC API an einen RPC-Node übermittelt
• QUIC-Verbindung: Der RPC-Node stellt eine QUIC-Verbindung zum Leader her und nutzt je nach Konfiguration offene oder Stake-gewichtete Verbindungen
• Stake-Weighted QoS: Ist der RPC-Node mit einem Validator mit Stake gekoppelt, nutzt er dessen Staked Connections und verbessert dadurch die Transaktionsleistung
• Weiterleitung an den Leader: Die Transaktion wird über diese Staked Connections an den Leader gesendet, wodurch Verzögerungen oder Verluste weniger wahrscheinlich sind
• Transaktionsverarbeitung: Die Transaktion durchläuft wie zuvor beschrieben die TPU und wird vom Leader verarbeitet

SWQoS verbessert den Transaktionslebenszyklus, indem es Validatoren mit Stake und den mit ihnen gekoppelten RPC-Nodes besseren Zugang zum Leader verschafft. Das senkt das Risiko von Verzögerungen durch Netzwerküberlastung. Dieser Mechanismus arbeitet mit Priority Fees zusammen, um die Transaktionsleistung zu verbessern.

SWQoS vs. Priority Fees: Der klare Unterschied

Bei Netzwerküberlastung sorgt SWQoS dafür, dass Transaktionen von Validatoren mit viel Stake seltener verzögert oder verworfen werden. Das System wird häufig mit einer Mautstraße verglichen: Validatoren mit mehr Stake erhalten Zugang zu weniger überlasteten Wegen, ähnlich wie zusätzliche Fahrspuren auf einer Autobahn. Das Bild oben zeigt ein Beispiel. In Colorado können Autofahrer im Stau stehen oder ein paar Dollar zusätzlich zahlen, um eine Mautspur zu nutzen. Die Express Lanes sind Colorados Netz aus Premiumspuren. Ihre Preise werden fortlaufend so angepasst, dass sie hoch genug sind, um den Verkehr flüssig zu halten. Die Staked Connections von Solana ähneln daher den Express Lanes in Colorado: Beide sind priorisierte Wege, die Überlastung für Premiumkunden reduzieren sollen.

Dennoch musst du zwischen SWQoS und Priority Fees unterscheiden. Die verbreitete Mautstraßen-Analogie kann den Unterschied zwischen diesen beiden Konzepten verwischen:

• Priority Fees greifen in der Banking Stage, wenn Leader Transaktionen anhand der gezahlten Gebühren priorisieren. Transaktionen mit höheren Gebühren sollen früher verarbeitet werden. Nutzer, die mehr zahlen, erhalten dadurch eine schnellere Ausführung.
• SWQoS verbessert den Zugang zu Verbindungen, beeinflusst aber nicht die Priorisierung von Transaktionen in der Transaktions-Queue des Leaders. SWQoS verschafft Validatoren mit Stake besseren Zugang zum Netzwerk und senkt damit das Risiko, dass Transaktionen aufgrund von Netzwerküberlastung verzögert oder verworfen werden

Priority Fees beeinflussen, wie Transaktionen angeordnet und verarbeitet werden, sobald sie sich in der Queue des Leaders befinden. SWQoS stellt dagegen sicher, dass Transaktionen von Validatoren mit Stake den Leader über einen priorisierten Weg erreichen. Beide Mechanismen sollen die Netzwerkleistung verbessern, greifen aber in unterschiedlichen Phasen des Transaktionslebenszyklus.

Die SWQoS-Kriege

SWQoS wird künftig ein grundlegender Bestandteil der Netzwerkinfrastruktur von Solana sein. Es optimiert die Transaktionsverarbeitung und priorisiert Verbindungen von Validatoren mit Stake zum Leader. Dadurch wird es das Ökosystem erheblich beeinflussen. Ich kann die Bedeutung dieser Tatsache nicht genug betonen.

Man könnte argumentieren, dass der Vorteil von Validatoren mit hohem Stake abnimmt, solange das Netzwerk nicht überlastet ist und Transaktionen nicht zeitkritisch sind. In diesem Fall hat das Netzwerk genug Kapazität, um Transaktionen unabhängig vom dahinterstehenden Stake-Gewicht schnell zu verarbeiten. Allerdings kann das Netzwerk angesichts der steigenden Nachfrage durch die bevorstehende breite Nutzung von Solana möglicherweise nicht immer jede Transaktion ohne Verzögerungen oder gelegentliche Verluste verarbeiten. Das bedeutet nicht, dass Solana nicht skalieren kann. Solana bietet wohl eine der besten, wenn nicht die beste Chance auf eine skalierbare Blockchain. Entscheidend ist: Mit wachsender Nachfrage bleibt SWQoS für eine hervorragende UX wichtig.

Dadurch wird die Rolle der Validatoren noch wichtiger. Das führt zu mehr Wettbewerb und Innovation, um den bestmöglichen Service anzubieten. Würde das nicht bedeuten, dass jeder seinen eigenen Validator betreiben möchte?   

Validatoren und Liquid Staking Tokens (LSTs)

Der Trend ist eindeutig: Jedes ernstzunehmende Solana-Protokoll wird einen Validator betreiben. Das wird notwendig sein, um die eigene Anwendung zu unterstützen. Falls du einen eigenen Validator betreiben möchtest, findest du im Helius-Blog eine Anleitung für den Einstieg.

Wir stehen am Beginn einer gewaltigen kambrischen Explosion von LSTs auf Solana, die durch SWQoS noch verstärkt wird. Allein in diesem Monat ist der gesamte Stake – also Native + LST – um rund 3,2 Millionen gestiegen. Der Marktwert der LSTs liegt allein in diesem Monat derzeit zwischen 6 und 9 Milliarden US-Dollar. Protokolle wie Sanctum dürften zu wichtigen Akteuren werden, da ihre Plattform Validatoren und Apps die Erstellung eigener LSTs ermöglicht. Außerdem ermöglicht Picasso Network Restaking auf Solana und dient als Hub, über den LSTs mehr Nutzen und Rendite erzielen können. LSTs mit zusätzlichem Nutzen lassen sich also bereits heute erstellen – und das in großem Umfang.

Es gibt jedoch einige potenzielle Einstiegshürden zu beachten.

Einstiegshürden

Trotz seiner potenziellen Vorteile schafft SWQoS mehrere Einstiegshürden. Insbesondere wurde in Version v1.17.31 des Agave-Clients eine Mindestanforderung an den Stake eingeführt, durch die Validatoren mit wenig Stake wie Peers ohne Stake behandelt werden. Das Problem bestand darin, dass Staked Nodes mit wenig Stake die Staked Connections missbrauchen konnten, indem sie unverhältnismäßig viel Bandbreite erhielten. Nodes mit einem Stake-Anteil unterhalb des Ergebnisses der folgenden Formel werden deshalb jetzt als Nodes ohne Stake behandelt:

stake / total_stake < 1 / (max packet per 100ms)

Das bedeutet, dass Clients mit weniger als ungefähr 15.000 SOL Stake jetzt als Validatoren ohne Stake gelten. Diese Anforderung könnte die ohnehin hohen finanziellen und technischen Voraussetzungen für den Betrieb eines Solana-Validators weiter verschärfen. Kleinere Akteure und unabhängige Validatoren könnten dadurch von der Teilnahme am Netzwerk ausgeschlossen werden. Die Anforderung entspricht ungefähr 3 Millionen US-Dollar, was auf den ersten Blick sehr viel ist. 

Wie Austin Federa jedoch erklärt, liegt der Schwellenwert nur bei einem Fünfundzwanzigtausendstel des gesamten Stakes und ist damit wohl niedrig. Wenn außerdem die Mehrheit der Validatoren im Wettbewerb um Stake ihre Leistung kontinuierlich verbessert, um den bestmöglichen Service anzubieten und ihre eigenen Erträge zu maximieren, profitiert das gesamte Netzwerk. Genau das beschreibt Toly als übergeordnetes Ziel von SWQoS.

Bei Helius senken wir die Einstiegshürde für alle kostenpflichtigen Tarife, wenn Transaktionen mit der von Helius empfohlenen Gebühr gesendet werden. Das heißt: Jeder Nutzer, der Transaktionen über einen kostenpflichtigen Shared-Tarif sendet, wird jetzt über unsere Staked Connections geleitet, sofern er mindestens den von unserer Priority Fee API empfohlenen Wert verwendet. Diesen Prozess haben wir außerdem mit unserer neuen Smart-Transactions-Funktion vereinfacht, die in unseren SDKs für Node.js und Rust verfügbar ist. Unabhängig vom verwendeten SDK geben Nutzer im einfachsten Fall ihr Schlüsselpaar und die gewünschten Anweisungen an. Wir übernehmen den Rest. Nutzer erhalten jetzt bereits ab 50 US-Dollar pro Monat mit einem Developer-Tarif Zugang zu gemeinsam genutzten Staked Connections. Wir bieten außerdem dedizierte Staked Connections an. Sie garantieren Bandbreite für Staked Connections und eignen sich für Großunternehmen, Quants und Handelsfirmen. Wenn du an dedizierten Staked Connections interessiert bist, kontaktiere unser Vertriebsteam.

Es ist wichtig zu beachten, dass sich Stake wahrscheinlich zunehmend bei Validatoren konzentrieren wird, die von großen Protokollen und RPC-Anbietern mit 0 % Provision betrieben werden. Helius ist ein Beispiel dafür: Wir können an anderer Stelle Geld verdienen und damit die Kosten für den Betrieb eines Validators teilweise decken. Damit verbessern wir die Dezentralisierung des Netzwerks, da ein Solana-natives Team einen führenden Validator betreibt. Gleichzeitig erhalten wir besseren Zugang zu Staked Connections und können so die Erfahrung unserer Nutzer verbessern.

Vertrauensannahmen

Wenn sich Stake wahrscheinlich bei Validatoren großer Protokolle und RPC-Anbieter konzentriert, solltest du deinen Stake einem Validator anvertrauen, der im besten Interesse von Solana handelt. SWQoS führt mehrere Vertrauensannahmen ein.

Eine der wichtigsten Vertrauensannahmen ist das notwendige hohe Maß an Vertrauen zwischen Validatoren und RPC-Nodes. Wie bereits beschrieben, ermöglicht SWQoS Leadern, Transaktionen von Validatoren mit Stake zu erkennen und zu priorisieren. Da RPC-Nodes keinen Stake besitzen, nicht abstimmen und nicht am Konsens teilnehmen, können sie nicht auf dieselbe Weise wie Validatoren mit Stake direkt von priorisierten Transaktionen profitieren. Um die Vorteile von SWQoS zu nutzen, müssen Validatoren und RPC-Nodes daher eine vertrauensvolle Beziehung aufbauen.

Diese Vertrauensbeziehung ist entscheidend, weil die Aktivierung von SWQoS die Weitergabe sensibler Netzwerkkonfigurationen erfordert und RPC-Nodes Einfluss auf die Priorisierung von Transaktionen gibt. Validatoren müssen sicherstellen, dass gekoppelte RPC-Nodes im besten Interesse des Netzwerks handeln und den erweiterten Stake nicht für böswillige Zwecke missbrauchen. Validatoren und RPC-Nodes sollten vorher vereinbaren und gemeinsam verstehen, wie die Staked Connections verwendet werden. Idealerweise erfolgt diese Einrichtung zwischen Parteien mit hohem gegenseitigem Vertrauen, etwa langjährigen Partnern oder Einheiten derselben Organisation.

Derzeit bleiben diese Beziehungen häufig verborgen. Auch künftig kann ich mir nicht vorstellen, dass RPC-Betreiber nicht mit Validatoren über Staked Overrides verhandeln werden. Wir brauchen mehr Transparenz, damit durchschnittliche Nutzer wissen, welche RPCs und Validatoren sie unterstützen. Die Nachfrage danach wird mit der Zeit nur steigen.

Fazit

SWQoS könnte die Netzwerkinfrastruktur von Solana grundlegend verändern. Es bietet viele Vorteile, darunter eine bessere Transaktionsleistung und höhere Sybil-Resistenz. Gleichzeitig führt es neue Herausforderungen und Vertrauensannahmen ein, mit denen wir sorgfältig umgehen müssen. SWQoS soll Transaktionen priorisieren, die von Validatoren mit Stake gesendet werden. Derzeit erzwingt jedoch nichts diese Priorität. Professionelle Validatoren überschreiben häufig die Standardeinstellungen und blockieren möglicherweise sogar bestimmte Akteure. Das unterstreicht, wie wichtig Vertrauen und Transparenz in den Beziehungen zwischen Validatoren und RPC-Nodes sind, damit SWQoS fair und effektiv genutzt wird. Unabhängig davon ist die Einführung von SWQoS ein wichtiger Schritt in der Entwicklung von Solana zu einem effizienten und widerstandsfähigen Netzwerk.

In diesem Artikel haben wir SWQoS und seinen Einfluss auf die Transaktionsverarbeitung untersucht. Außerdem haben wir wichtige Unterschiede behandelt, darunter den zwischen SWQoS und Priority Fees. Hinzu kamen der Aufstieg der Validatoren und LSTs, potenzielle Einstiegshürden und die damit verbundenen Vertrauensannahmen. Damit haben wir einen wichtigen Ausgangspunkt für künftige Diskussionen geschaffen. Nur wenn du all diese Elemente verstehst, kannst du SWQoS effektiv nutzen und Solana als Ganzes verbessern.

Wenn du bis hierhin gelesen hast: Vielen Dank, Anon! Gib unten deine E-Mail-Adresse ein, damit du keine Neuigkeiten zu Solana verpasst. Bereit, tiefer einzusteigen? Entdecke noch heute die neuesten Artikel im Helius-Blog und setze deine Reise mit Solana fort.

Weitere Ressourcen

• Bericht und Gegenmaßnahmen zum Ausfall von Solana Mainnet Beta am 30.04.2022
• Leitfaden zu Stake-Weighted Quality of Service auf Solana
• So richtest du einen Solana-Validator ein
• Smart Transactions senden
• Schulung für Solana-Validatoren – Stake-Weighted QoS