Solana-Gebühren in Theorie und Praxis

Einführung

Die Gebührenstruktur von Solana soll die Leistung des Netzwerks aufrechterhalten und zugleich ungleichmäßige Schwankungen bei Angebot und Nachfrage ausgleichen. Gebühren dienen auf jeder Blockchain dazu, Spam zu verhindern und Validatoren Anreize zu bieten. Bei Solana werden einige dieser Gebühren dynamisch an die Netzwerkbedingungen angepasst. So kann das Netzwerk die aktuelle Nachfrage genauer bepreisen.

Gebühren sind bei Solana ein viel diskutiertes Thema. „Lokale Gebührenmärkte“ geben Solana einen gewissen Spielraum, um Blockspace und bestimmte Accounts genauer zu bepreisen. Die aktuelle Implementierung ist alles andere als perfekt, bietet aber grobe Garantien für die Reihenfolge auf Account-Ebene. Solana befindet sich noch in einer frühen Phase. Doch mehr Stake und Aktivität im Netzwerk erfordern eine tiefere Diskussion und Analyse der direkten und indirekten Auswirkungen aller protokollinternen Änderungen, etwa am Gebührenmodell.

In diesem Beitrag betrachten wir Gebühren sowohl theoretisch als auch ihre konkrete Ausprägung onchain. Einige haben Solana wegen seines Stake-gewichteten Designs für QoS und Turbine als zentralisiert und zentralisierungsfördernd kritisiert. Doch selbst über viele Jahre hinweg zeigt sich eine deutliche Diskrepanz zwischen dieser Kritik und der Realität. Daher wollen wir umfassend analysieren, wie sich Gebühren im Onchain-Verhalten auswirken.

Gebühren in der Theorie

Das Gebührensystem von Solana besteht aus zwei Komponenten: der Basisgebühr und der Prioritätsgebühr. Im Allgemeinen sollte jede Komponente idealerweise den folgenden Zweck erfüllen:

• Basisgebühren: Recht zur Nutzung der Netzwerkressourcen
• Prioritätsgebühren: bestimmen die Reihenfolge in der Transaktionswarteschlange eines Leaders

Basisgebühr

Die Basisgebühr liegt derzeit bei 0,000005 SOL (5.000 Lamports) pro Signatur und bildet die Grundlage der Transaktionskosten. Eine Adresse zahlt diese Gebühr für das Recht, die Ressourcen des Netzwerks zu nutzen. Es handelt sich um eine einmalige Pauschalzahlung im Voraus an das Netzwerk – unabhängig davon, wie viele Ressourcen die Ausführung der Transaktion tatsächlich verbraucht oder ob sie überhaupt ausgeführt wird. Solana-Transaktionen fordern vorab eine bestimmte Anzahl von Compute Units (CUs) an. Wird diese Zahl überschritten, schlägt die Transaktion fehl. Daher haben Entwickler derzeit kaum oder gar keine finanziellen Anreize, die angeforderten Compute Units zu minimieren.

Prioritätsgebühren

Nutzer können zusätzlich eine Prioritätsgebühr zahlen, um ihre Transaktionen zu beschleunigen und deren Chance auf Aufnahme in einen Block zu erhöhen. Diese Zahlung für eine bevorzugte Behandlung bietet jedoch keine deterministische Garantie. Es wird daran gearbeitet, den Determinismus von Transaktionen zu verbessern. Wesentliche Änderungen am Scheduler werden voraussichtlich mit Version 1.18 eingeführt.

Nebenbei bemerkt: Vote-Transaktionen haben keine zugehörige Prioritätsgebühr und werden anders behandelt als Standardtransaktionen.

Der Anreiz für Validatoren, Transaktionen mit Prioritätsgebühren aufzunehmen, liegt außerhalb der Runtime. Leader erhalten 50 % der Prioritätsgebühr, wenn sie eine Transaktion in ihren Block aufnehmen. Die übrigen 50 % werden verbrannt.

Heute nutzen die meisten Validatoren (über 80 %) unveränderte Versionen des Clients von Solana Labs oder Jito-Solana. Diese Validatoren überlassen die „Blockproduktion“ also dem standardmäßigen Scheduler. Einige Nutzer bei Solana bezeichnen die „Blockreihenfolge“ als „Blockproduktion“, obwohl dieser Begriff bei Ethereum etwas völlig anderes bedeutet. Einige Teams haben den Client-Code angepasst und komplexere Scheduler implementiert. Dadurch können sie die Reihenfolge besser steuern und teilweise MEV extrahieren, indem sie Transaktionen neu anordnen oder Sandwich-Angriffe durchführen.

Indeterminismus bei Prioritätsgebühren

Die aktuelle Implementierung des Schedulers garantiert nicht, dass Transaktionen mit höheren Prioritätsgebühren in einen bestimmten Block aufgenommen werden. Sie bietet lediglich eine grobe Zusicherung, dass Transaktionen mit Prioritätsgebühren mit höherer Wahrscheinlichkeit in einem bestimmten Block landen. Die aktuelle Scheduler-Implementierung nutzt vier Ausführungskerne. Zwei weitere Kerne sind für Vote-Transaktionen reserviert.

Jeder Thread verwaltet seine eigene Warteschlange und priorisiert Pakete unabhängig, ohne die von anderen Threads verarbeiteten Pakete zu kennen. Jeder Thread durchläuft kontinuierlich seine Warteschlange vom Anfang bis zum Ende und versucht dabei, Transaktionen zu sperren und auszuführen. Wenn ein Thread seinen aktuellen Durchlauf beendet, nimmt er weitere Pakete auf und startet den nächsten Durchlauf.

Dadurch kann eine Transaktion mit hoher Priorität am Anfang der Warteschlange eines Threads verarbeitet werden, während ein anderer Thread gleichzeitig das Ende seiner eigenen Warteschlange erreicht und dabei eine Transaktion mit demselben Account verarbeitet.

Die konkreten Details der aktuellen und zukünftigen Scheduler-Implementierung behandeln wir in einem separaten Beitrag. Hier genügt die Erkenntnis, dass Prioritätsgebühren nur intra-thread (innerhalb einer Lane) wirken und nicht inter-thread (zwischen Lanes). Daran wird deutlich, dass der Scheduler alles andere als perfekt ist und „Jitter“ aufweist.

Gebühren in der Praxis

Erfolgreiche Aufnahme von Transaktionen

Gebühren haben großen Einfluss darauf, ob eine Transaktion aufgenommen wird, sind aber nicht der einzige entscheidende Faktor. Transaktionen können beispielsweise allein durch den Verlust eines UDP-Netzwerkpakets scheitern. Bei hoher Netzwerkaktivität können Validatoren mehr Transaktionen erhalten, als sie verarbeiten können. Validatoren können überschüssige Transaktionen zwar über den Mechanismus tpu_forwards weiterleiten, aber nur eine begrenzte Datenmenge verarbeiten. Zudem lässt sich jede Transaktion nur begrenzt oft weiterleiten, bis der Blockhash abläuft. Stake-gewichtete Dienstqualität mildert einige dieser Probleme für Adressen mit höherem Stake. Sie erhalten reservierte Bandbreite, wodurch ihre Transaktionen mit höherer Wahrscheinlichkeit aufgenommen werden.

Es gibt außerdem zwei seltener diskutierte Gründe für den Ausfall von Transaktionen. Der erste betrifft Abweichungen innerhalb eines RPC-Pools. Ein Teil des RPC-Pools kann den anderen voraus sein und dadurch Koordinationsprobleme verursachen. Wird etwa der recentBlockhash einer Transaktion aus einem aktuelleren Segment abgerufen und die Transaktion anschließend an ein langsameres Segment übermittelt, erkennt dieses den aktualisierten Blockhash möglicherweise nicht und verwirft die Transaktion. Entwickler können solche Probleme bei der Übermittlung erkennen, wenn sie in der Funktion sendTransaction Preflight-Prüfungen aktiviert haben.

Ein weiteres Problem entsteht durch temporäre Netzwerk-Forks. Wenn ein Validator bei der Verarbeitung seiner Blöcke zurückliegt, können Transaktionen auf einem Minderheits-Fork landen, der nicht kanonisch wird. Verweist ein Client in seiner Transaktion auf einen recentBlockhash, der nur in diesem Minderheits-Fork existiert, und verwirft das Netzwerk den Fork vor der Verarbeitung der Transaktion, wird die Transaktion verworfen, da der Blockhash nicht mehr gefunden werden kann.

Prioritätsgebühren

In der Praxis sehen wir, dass Prioritätsgebühren trotz ihrer Schwächen im großen Maßstab funktionieren. Transaktionen mit Prioritätsgebühren werden mit höherer Wahrscheinlichkeit in Blöcke aufgenommen. Höhere Prioritätsgebühren erhöhen diese Wahrscheinlichkeit zusätzlich.

Daten von Helius RPC zeigen, dass Transaktionen mit Prioritätsgebühren mit höherer Wahrscheinlichkeit aufgenommen werden. Außerdem werden sie durchweg schneller aufgenommen:

Am 21. Januar stiegen die durchschnittlichen Prioritätsgebühren wegen des mockJUP-Airdrops stark an. Er diente als Vorbereitung für den eigentlichen JUP-Airdrop in der folgenden Woche. Obwohl sich die Nachfrage nach Blockspace deutlich veränderte, bemerkten die Nutzer bei der Aufnahmerate und -dauer von Transaktionen relativ wenig davon.

Diese UX wird hauptsächlich durch die Solana-RPC-Methode getRecentPrioritizationFees ermöglicht. Damit können Entwickler die Prioritätsgebühr, die sie einer Transaktion hinzufügen sollten, präzise bestimmen. Der Endpoint gibt eine Liste der Prioritätsgebühren aus den letzten 150 Blöcken zurück, mit denen mindestens eine Transaktion für die jeweilige Adresse und die jeweiligen Eingabeparameter erfolgreich aufgenommen wurde. Dies liefert eine Momentaufnahme des erforderlichen Mindestwerts für Prioritätsgebühren, ist aber nur begrenzt nützlich. Alternativ bietet Helius eine Priority Fee API, die zusätzliche Berechnungen durchführt und dadurch eine bessere Schätzung der Prioritätsgebühr liefert.

Prioritätsgebühren funktionieren theoretisch bis zu einem gewissen Grad wie vorgesehen. Die kommenden Scheduler-Änderungen in Version 1.18 sollen die Aufnahme von Transaktionen jedoch durch Verbesserungen am Scheduler deterministischer machen. Dadurch sollte weniger Spam onchain landen, da die dominante Strategie für die Aufnahme einer Transaktion nicht länger das Fluten der Chain mit Transaktionen voraussetzt.

Basisgebühr

Die Basisgebühr bei Solana ist eindeutig zu niedrig. Blöcke erreichen ihre Kapazitätsgrenze, während die Gebühr statisch bleibt. Daher kann sie keinen markträumenden Preis für Blockspace erreichen. Bei Ethereum wird die dynamische Basisgebühr über den Controller-Mechanismus von EIP-1559 umgesetzt. Dieser betrachtet die jüngsten Blöcke und strebt eine Auslastung von 50 % an.

Solana berechnet statisch 5.000 Lamports pro Signatur, üblicherweise eine Signatur pro Transaktion. Damit ist die Gebühr ineffektiv, da sie weder Veränderungen bei der Nachfrage nach Blockspace noch bei der Nutzung der Validator-Ressourcen abbildet. Dadurch wird die Prioritätsgebühr faktisch als marktbasierte Alternative ausgelagert. Das belastet das Netzwerk zusätzlich, weil Validatoren weitere Transaktionen verarbeiten, die wahrscheinlich ohnehin nie aufgenommen würden. Zudem besteht die dominante Strategie darin, eine große Zahl von Transaktionen mit minimalen Prioritätsgebühren zu übermitteln. Das verursacht erhebliche negative externe Effekte für die UX aller Netzwerkteilnehmer.

Anreize

RPCs haben einen Anreiz, nachgelagerten Systemen korrekte Informationen zu übermitteln, um bei minimalen Kosten die höchste Aufnahmerate für Transaktionen zu erreichen. Durch die Integration mit Validatoren mit hohem Stake erhalten RPCs ein genaueres Bild vom aktuellen Netzwerkzustand, da viele Mechanismen von Solana Stake-gewichtet sind. So entsteht eine symbiotische Beziehung: Validatoren mit erheblichem Stake und integrierte RPCs können die Effizienz und Zuverlässigkeit der Transaktionsverarbeitung verbessern. Daraus kann eine Rückkopplungsschleife entstehen, die die Position der Validatoren mit dem höchsten Stake weiter festigt.

Darüber hinaus werden RPCs, die derzeit wie Validatoren ohne Stake behandelt werden, künftig selbst Stake-gewichtet. RPCs können versuchen, eigenständig Stake zu gewinnen, ohne mit einem Validator zusammenzuarbeiten. Es ist nicht ungewöhnlich, dass Anwendungen für eine stärkere vertikale Integration eigene Validatoren betreiben. Das ermöglicht mehr Kontrolle über die UX der Endnutzer und die Lieferkette für Transaktionen und MEV.

Obwohl die wirtschaftlichen Anreize auf eine Zentralisierung des Stakes hindeuten, kam es bei Solana bisher nicht zu einer großflächigen Kapitalbündelung für Stake-gewichtete Vorteile. Dafür könnte es mehrere Gründe geben:

• Einzelne Teilnehmer könnten die lokale Maximierung der Dezentralisierung als dominante Strategie für langfristige Vorteile des Netzwerks betrachten. Dafür sind vor allem die Kultur und die soziale Ebene von Solana verantwortlich.
• Die Teilnehmer bei Solana waren bisher überwiegend Privatanleger und Prosumer. Sie reagieren weniger sensibel auf Renditen als professionelle Unternehmen. Steigen Aktivitätsniveau und absolute Renditen, könnten sich dadurch die Demografie und Renditesensitivität der Teilnehmer verändern.
• Einzelne Teilnehmer koordinieren die Vermarktung ihrer differenzierten Produkte nicht ausreichend.

Fazit

In diesem Beitrag haben wir die grundlegende Theorie des Gebührenmechanismus von Solana und seine Onchain-Auswirkungen auf das Netzwerk ausführlich beschrieben. Gebühren schaffen Anreize, die erhebliche externe Effekte verursachen und das Verhalten aller Teilnehmer bei Solana beeinflussen.

Mechanismen wie die Basis- und Prioritätsgebühr von Solana sind in ihrer aktuellen Implementierung nicht perfekt. Die Basisgebühr lässt sich nicht anpassen und spiegelt das aktuelle Gleichgewicht von Angebot und Nachfrage nicht wider. Das führt zu Problemen wie Netzwerküberlastung und ineffizienter Ressourcenverteilung. Prioritätsgebühren weisen wegen der aktuellen Scheduler-Implementierung einen gewissen Indeterminismus auf. Künftige Updates wie die erwarteten Scheduler-Änderungen versprechen eine deterministischere und effizientere Transaktionsverarbeitung. Sie könnten das heute beobachtete Onchain-Verhalten grundlegend verändern.

Neue Vorschläge zeichnen sich bereits ab, darunter exponentielle Gebühren für Accounts mit Schreibsperre. Sie sollen die Kosten von Transaktionen genauer bepreisen, indem sie den Zugriff auf Accounts gezielt sperren. Außerdem wird über einen dynamischen Basisgebührenmechanismus diskutiert, der den Zugriff auf den State genauer bepreist.

Das Zusammenspiel von Gebühren, Validatoren und RPCs bildet ein komplexes Netz aus Anreizen. Theoretisch haben Validatoren und RPCs einen Anreiz, sich zu integrieren und ihr Stake-Gewicht zu erhöhen. Das kann Bedenken hinsichtlich einer Zentralisierung auslösen. In der Praxis konnte Solana jedoch eine dezentrale Verteilung von Betreibern und Stake bewahren. Wahrscheinliche Gründe dafür sind die gemeinschaftsgetriebene Governance, technische Hürden, wirtschaftliche Gegenanreize und Optimierungsfunktionen, die derzeit nicht primär auf Rendite ausgerichtet sind.