Die Wahrheit über lokale Gebührenmärkte auf Solana

Praktische Erkenntnisse

• Lokale Gebührenmärkte (LFMs) ermöglichen Solana, granulare Gebühren für einzelne Zustandsbereiche anhand ihrer Auslastung festzulegen. Transaktionen zahlen Gebühren auf Basis des konkreten Zustands, in den sie schreiben. Dadurch erhöhen lokale Hotspots nicht die Gebühren in der gesamten Blockchain. 
• LFMs sind entscheidend für Solanas Vision einer skalierbaren, einheitlichen Basisschicht, auf der alle Anwendungen nahtlos nebeneinander bestehen. Ohne LFMs führen Gebührenspitzen in einem Teil der Chain zu höheren Gebühren für alle Transaktionen. Dieses Problem tritt häufig in anderen Netzwerken auf, die bei der Preisbildung für Blockspace ausschließlich auf globale Gebührenmärkte setzen.
• Als die wirtschaftliche Aktivität auf Solana Ende 2023 zunahm, wurden mehrere kritische Schwächen der ursprünglichen LFM-Implementierung sichtbar. Besonders auffällig war die nicht deterministische Priorisierung durch den Scheduler. Transaktionen wurden hauptsächlich nach ihrer Ankunftszeit beim Block-Builder sortiert. Priority Fees waren nur ein nachrangiges Kriterium.
• Mit dem Agave-Client-Update v1.18 im Mai 2024 wurden ein neuer Transaktions-Scheduler und eine verbesserte Formel für die Transaktionspriorität eingeführt. Der Scheduler erstellt einen Abhängigkeitsgraphen, um die Verarbeitung und Priorisierung kollidierender Transaktionen über mehrere Threads hinweg besser zu steuern. Dieses große Update verbesserte die Fähigkeit des Protokolls, Transaktionen deterministisch zu ordnen, erheblich.
• Eine hilfreiche Kennzahl zur Bewertung effektiv funktionierender LFMs ist der Vergleich zwischen Median und Durchschnitt der Priority Fees von Transaktionen. Gebühren für nicht umkämpften Zustand (Median des 50. Perzentils) sollten niedrig bleiben. Gebühren für umkämpften Zustand sollten bei steigender Nachfrage stark zunehmen und den Durchschnitt nach oben ziehen. Aktuelle Daten bestätigen dieses Muster. Im November 2024 erreichten die durchschnittlichen Gebühren für Non-Vote-Transaktionen mit mehr als 0,0003 SOL ein Allzeithoch. Der Median blieb jedoch stabil bei 0,00000861 SOL und war damit etwa 35-mal niedriger.
• Heute funktionieren Solanas LFMs, es gibt jedoch noch erhebliches Verbesserungspotenzial. Eine von Anza-Ingenieuren durchgeführte Analyse der Thread-Workloads in der Banking Stage zeigt, dass ein Scheduler-Fehler den Validator-Client daran hindert, seine volle Kapazität zu nutzen. Deshalb erreicht der Agave-Client nur einen Bruchteil seines Potenzials. Außerdem gibt es keine formale Spezifikation dafür, wie Transaktionen geordnet werden sollen.
• Den aktuellen Priority-Fee-APIs fehlt die nötige Ausgereiftheit, um Entwicklern deterministische Ergebnisse zu liefern. Jeder große RPC-Anbieter bietet eine eigene Priority-Fee-API an. Das könnte zu einer abgeschwächten Form des Vendor-Lock-ins führen. Die zentrale Open-Source-Implementierung der RPC API berücksichtigt wichtige Netzwerkdynamiken wie den Einfluss von Jito nicht und liefert daher ungenaue Gebührenschätzungen.
• Ohne eine deterministische Methode zur Berechnung von Priority Fees gehen Entwickler oft vorsichtig vor und zahlen zu viel, um die Verarbeitung ihrer Transaktionen zu garantieren. Alternativ verwenden sie übermäßig häufig Jito-Tips als Ersatzmechanismus, selbst bei Transaktionen, die keine Position am Blockanfang benötigen.
• Es wurden verschiedene Strategien vorgeschlagen, um Solanas Gebührenstruktur weiter zu verbessern. Dazu gehören exponentielle Write-Lock-Gebühren und dynamische Basisgebühren. Das Netzwerk muss noch Wege finden, durch wirtschaftlichen Gegendruck Spam unattraktiv zu machen und gleichzeitig die Gebühren für echte menschliche Nutzer niedrig zu halten.

Einführung

Gebührenmärkte sind wirtschaftliche Mechanismen, die knappen Blockspace durch die dynamische Anpassung von Transaktionsgebühren effizient den wertvollsten Transaktionen zuweisen. Die Zahlungsbereitschaft einer Transaktion dient dabei als Näherungswert für ihren Wert. LFMs verfeinern dieses allgemeine Konzept, indem sie granulare Gebühren für einzelne Zustandsbereiche anhand ihrer Auslastung festlegen. Zwei Transaktionen gelten als kollidierend, wenn sie auf denselben Zustand zugreifen – entweder durch zwei Schreibvorgänge oder durch einen Lese- und einen Schreibvorgang auf dasselbe Konto.

Mit LFMs zahlen Transaktionen Gebühren auf Basis des konkreten Zustands, in den sie schreiben. Dadurch erhöhen lokale Hotspots nicht die Gebühren in der gesamten Blockchain. Transaktionen, die auf stark nachgefragten oder umkämpften Zustand zugreifen, zahlen höhere Gebühren. Interaktionen mit weniger gefragtem Zustand bleiben günstiger. Das ist wichtig, weil Solana dank paralleler Ausführung nicht kollidierende Transaktionen besser verarbeitet.

Globale Gebührenmärkte verlangen dagegen einen einheitlichen Preis für den Zugriff auf den Netzwerkzustand. Alle Transaktionen konkurrieren unabhängig von den beteiligten Konten gleichberechtigt um die Aufnahme. Das mit EIP-1559 implementierte Gebührenmodell von Ethereum ist ein treffendes Beispiel für globale Gebührenmärkte. EIP-1559 passt eine dynamische Basisgebühr anhand der Netzwerknachfrage an, um die optimale Compute-Nutzung (Gas) pro Block aufrechtzuerhalten. Wenn sich die Blockkapazität füllt, steigen die Gebühren für alle Transaktionen. Wallets berechnen Gebühren anhand der aktuellen Basisgebühr und des Gaslimits der Transaktion. Dieser Ansatz ist im Protokoll verankert und ermöglicht vorhersehbare Gebührenberechnungen. Er kann stark nachgefragte Hotspots jedoch nicht vom übrigen Netzwerk isolieren. Wenn die Gebühren steigen, steigen sie für alle Transaktionen.

Eine hohe Nachfrage nach bestimmten Zustandsbereichen ist kein exklusives Problem von Blockchains. Diese Herausforderung ähnelt dem Hotspot-Key-Problem, das oft als „Prominentenproblem“ bezeichnet wird und häufig in sozialen Web2-Anwendungen auftritt.

Mit diesem Artikel möchten wir eine verständliche Analyse der LFMs von Solana bieten. Die Arbeit ist in folgende Abschnitte gegliedert:

• Grundlagen der Solana-Gebühren: Vermittelt ein grundlegendes Verständnis dafür, wie Transaktionen heute auf Solana verarbeitet werden.
• Frühe Probleme lokaler Gebührenmärkte: Untersucht die anfänglichen Probleme und Schwächen früher LFM-Implementierungen.
• Das Update auf den zentralen Scheduler v1.18: Beleuchtet ein entscheidendes Update aus dem Jahr 2024, das die Funktionalität von LFMs deutlich verbessert hat.
• Messung der Effektivität lokaler Gebührenmärkte: Liefert relevante Daten, um den heutigen Zustand der LFMs auf Solana zu verstehen.
• Bestehende Probleme und Verbesserungspotenzial: Erläutert ungelöste Probleme und Bereiche, die angegangen werden müssen, damit LFMs ihr volles Potenzial erreichen.
• Vorgeschlagene Lösungen: Bewertet Lösungsvorschläge zur Verbesserung von LFMs und zur Einführung besserer wirtschaftlicher Anreize für eine differenziertere Preisbildung von Blockspace.

Wenn du bereits mit den Transaktionsgebührenstrukturen von Solana vertraut bist, kannst du den folgenden Grundlagenabschnitt überspringen.

Grundlagen der Solana-Gebühren

Solana-Transaktionen bestehen aus zwei Gebühren: der Basisgebühr und der Priority Fee. Die Basisgebühr ist derzeit auf 5.000 Lamports pro Signatur festgelegt. Die meisten Solana-Transaktionen haben eine Signatur. Die Priority Fee wird in Microlamports, also einem Millionstel eines Lamports, pro angeforderter Compute Unit (CU) angegeben. Die Gebühren werden vom Konto des Gebührenzahlers, also des Signierers, abgebucht. Verfügt der Zahler nicht über genügend Lamports, um die Transaktion zu bezahlen, wird sie verworfen. Zum Zeitpunkt der Veröffentlichung behält der Block-Builder jeweils 50 % der Basisgebühr und der Priority Fee als Anreiz für die Aufnahme der Transaktion in den Block. Die übrigen 50 % werden verbrannt. Nach der erfolgreichen Governance-Abstimmung über Vorschlag SIMD-096 im Mai letzten Jahres wird sich dies ändern: Der Block-Builder behält dann 100 % der Priority Fees. Beispiel: 

Eine Transaktion hat eine Signatur und fordert 500.000 CUs an. Der Absender legt eine Priority Fee von 50.000 Microlamports pro angeforderter CU fest. Die Gesamtgebühr der Transaktion beträgt 5.000 Lamports + (500.000 angeforderte CUs * 50.000 Microlamports pro angeforderter CU) = 25.000 Lamports oder 0,000025 SOL.

Validatoren verfügen nur über begrenzte Rechenressourcen. Das Protokoll begrenzt die gesamten Rechenressourcen pro Block auf 48 Millionen CUs. Dieser Wert wurde empirisch danach bestimmt, wie viel Validatoren vernünftigerweise verarbeiten können, um Blockzeiten von 400 Millisekunden zu erreichen. Pro Konto und Block sind maximal 12 Millionen CUs zulässig. Das maximale Compute-Budget pro Transaktion beträgt 1,4 Millionen CUs. Transaktionsnachrichten sind außerdem auf eine maximale Größe von 1.232 Byte begrenzt. Das entspricht der minimalen Übertragungseinheit von IPv6 (1.280 Byte) abzüglich der Header.

Um den Missbrauch von Rechenressourcen zu verhindern, wird jeder Transaktion auf Solana ein Compute-Budget zugewiesen. Standardmäßig legt das Netzwerk ein maximales Limit von 200.000 Compute Units (CU) pro Anweisung fest. Transaktionen können jedoch ein eigenes Compute-Unit-Limit angeben, indem sie eine `SetComputeUnitLimit`-Anweisung einfügen. Das ermöglicht eine effizientere Ressourcenzuweisung. Die Codebasis des Agave-Clients listet die CU-Kosten verschiedener Operationen auf.

Solana verlangt, dass jede Transaktion eine vollständige Liste aller Kontoadressen angibt, die während der Transaktion gelesen oder beschrieben werden. Diese Liste ist auf 35 Adressen begrenzt und kann durch Onchain-Address-Lookup-Tables erweitert werden. Das Erstellen von Adresslisten verursacht zusätzlichen Aufwand für Entwickler, ist aber der Schlüssel zu vielen Optimierungen von Solana. Dazu gehören die parallele Transaktionsausführung und lokale Gebührenmärkte.

Frühe Probleme mit Solanas lokalen Gebührenmärkten

Als die wirtschaftliche Aktivität auf Solana Ende 2023 zunahm, wurden mehrere kritische Schwächen der ursprünglichen LFM-Implementierung sichtbar. Etwa zu dieser Zeit veröffentlichte Eugene Chen von Ellipsis Labs im Umbra-Research-Artikel „Solana Fees, Part 1“ eine umfassende Analyse dieser Herausforderungen. Nachfolgend fassen wir Chens wichtigste Punkte zusammen.

Fehlende Anreize für präzise CU-Anforderungen

Solanas Gebührenstruktur berechnet Basisgebühren pro Signatur, ohne die verwendeten oder angeforderten Compute Units (CUs) zu berücksichtigen. Gleichzeitig bieten Priority Fees bei Überlastung nur begrenzte Anreize, die CU-Nutzung zu reduzieren. Dieses Design motiviert Transaktionsabsender kaum dazu, ihre Compute-Nutzung zu optimieren oder ihre CU-Anforderungen an den tatsächlichen Bedarf anzupassen. Daher fordern Transaktionen häufig zu viele CUs an und machen den Scheduling-Prozess des Netzwerks ineffizienter.

Anreize für Prioritätsmechanismen außerhalb des Protokolls

Das Verbrennen von 50 % der Priority Fees motiviert Transaktionsabsender dazu, das Protokoll zu umgehen. Sie können mit Block-Buildern kooperieren und Offchain-Zahlungen für bevorzugten Zugriff vereinbaren. Dieses Verhalten zeigt sich in der wachsenden Nutzung von Jito-Auktionen. Validatoren, die den Jito-Agave-Client ausführen, profitieren von höheren Gebühreneinnahmen und können diese Gewinne über Jito-MEV-Provisionsprämien effizient an delegierende Staker ausschütten. Mit der zunehmenden Verbreitung von Jito-Agave-Clients haben sich Jito-Bundles in vielen Szenarien als überlegener Dienst für die Transaktionsübermittlung erwiesen. 

Nicht deterministische Priorisierung durch den Scheduler

Weder der Konsens von Solana noch der Scheduler erzwingen eine strikte Transaktionsreihenfolge anhand der Priority Fees. Transaktionen werden hauptsächlich nach ihrer Ankunftszeit beim Block-Builder sortiert. Priority Fees sind nur ein nachrangiges Kriterium. Höhere Priority Fees können bei umkämpftem Zustand die Wahrscheinlichkeit einer Aufnahme erhöhen, der Sortierprozess bleibt jedoch nicht deterministisch. Netzwerk-Jitter vor dem Erreichen der Transaction Processing Unit (TPU) und interner Jitter im Scheduler erhöhen die Unvorhersehbarkeit zusätzlich.

Dieser fehlende Determinismus beeinträchtigt die Vorhersehbarkeit und Zuverlässigkeit der Transaktionsausführung. Nutzer fluten das Netzwerk deshalb mit Transaktions-Spam, um ihre Chancen auf eine schnellere Aufnahme zu erhöhen. Ab einem bestimmten Schwellenwert bringen höhere Priority Fees jedoch immer weniger, was ihre Wirksamkeit als Mechanismus für eine bessere Transaktionsplatzierung untergräbt. Solanas gemeinsam genutzter Blockspace ist letztlich einer klassischen „Tragik der Allmende“ zum Opfer gefallen. Einzelne Akteure haben aus Eigeninteresse zur Übernutzung und Ineffizienz dieser öffentlichen Ressource beigetragen.

Das Update auf den zentralen Scheduler v1.18

Die ursprüngliche Implementierung des Agave-Client-Schedulers bot nur eine schwache Garantie dafür, dass Transaktionen mit hohen Priority Fees bessere Chancen auf die Aufnahme in einen bestimmten Block hatten. Die Transaction Processing Unit (TPU) des Leaders verwendet sechs parallele Threads: Vier verarbeiten Non-Vote-Transaktionen, zwei sind für Vote-Transaktionen reserviert. Jeder der vier Threads für Non-Vote-Transaktionen verwaltet eine eigene Warteschlange. Dort warten eingehende Transaktionen darauf, für die Ausführung in Einträge gruppiert zu werden. Zuvor wurden Transaktionen diesen Threads zufällig zugewiesen. Die Warteschlangen priorisierten Pakete unabhängig voneinander und wussten nicht, welche Pakete andere Threads verarbeiteten.

In diesem System durchläuft jeder Thread seine Warteschlange und versucht, Transaktionen zu sperren und auszuführen. Sobald ein Thread seinen aktuellen Durchlauf beendet hat, sammelt er weitere Pakete und beginnt den Prozess erneut. Diese Struktur erschwert den effektiven Einsatz von Priority Fees. Eine Transaktion mit hoher Priorität kann beispielsweise am Anfang der Warteschlange eines Threads stehen, während ein anderer Thread gleichzeitig eine Transaktion mit niedrigerer Priority Fee vom Ende seiner Warteschlange verarbeitet, die dasselbe Konto betrifft. Priority Fees beeinflussten die Transaktionsreihenfolge nur innerhalb einzelner Threads (Intra-Thread), nicht über alle Threads hinweg (Inter-Thread). Deshalb verwendete jede Warteschlange einen hybriden Sortiermechanismus, der First-in-first-out-Verarbeitung (FIFO) mit Priority Fees kombinierte. Eine globale Reihenfolge über mehrere Threads hinweg wurde jedoch nicht erzwungen.

Bevor ein Thread eine Transaktion ausführen kann, muss er die erforderlichen Kontosperren erhalten. Sind die nötigen Schreibsperren nicht verfügbar, wird die Transaktion erneut in die Warteschlange gestellt. Die zufällige Zuweisung von Transaktionen zu Threads verschärft dieses Problem, da derselbe Transaktionstyp an unterschiedlichen Positionen im mehrthreadigen Scheduling-System landen kann. Diese stochastische Struktur des Schedulers erzeugt Jitter und damit Schwankungen bei der Platzierung einer Transaktion innerhalb eines Blocks.

Mit dem Agave-Client-Update v1.18 im Mai 2024 kam ein neuer Transaktions-Scheduler, auch zentraler Scheduler genannt. In dieser überarbeiteten Struktur erstellt der zentrale Scheduler einen Abhängigkeitsgraphen, den sogenannten Prio-Graphen. Damit steuert er die Verarbeitung und Priorisierung kollidierender Transaktionen über alle Threads hinweg besser. Dieses große Update verbesserte Solanas Fähigkeit, Transaktionen deterministisch zu ordnen, erheblich. Transaktionen mit höheren Priority Fees werden seitdem mit größerer Wahrscheinlichkeit in Blöcke aufgenommen.

Der Prio-Graph ist ein gerichteter azyklischer Graph (DAG), der beim Hinzufügen neuer Transaktionen dynamisch aktualisiert wird. Transaktionen werden im Graphen zu Ausführungsketten angeordnet und nach zeitlicher Priorität verarbeitet. Bei kollidierenden Transaktionen bestimmt die Priority Fee die Einfügereihenfolge. Dieser Ansatz minimiert Sperrkonflikte, ermöglicht die reibungslose Ausführung von Transaktions-Batches und reduziert Verzögerungen durch Ressourcenkonflikte. Die Prüfung der Transaktionsvorkompilierung wurde zur Leistungssteigerung in Worker-Threads ausgelagert und ermöglicht so eine effizientere Verarbeitung. 

Das aktualisierte Scheduler-Design verbessert Skalierbarkeit und Flexibilität deutlich. Die Anzahl der Threads kann potenziell erhöht werden, ohne das Risiko zusätzlicher Sperrkonflikte zu steigern. Darüber hinaus hat der zentralisierte Scheduling-Ansatz die Erzeugung von Prämien verbessert und die Einnahmen vieler Validator-Betreiber erhöht.

Eine detailliertere Aufschlüsselung des zentralen Schedulers findest du in unserem früheren Helius-Blogbeitrag zum Agave-Update 1.18.

Effektivere Prioritätsberechnung

Zusammen mit dem Scheduler-Update wurde die Formel für die Transaktionspriorität verbessert. Transaktionen mit geringerem Compute-Bedarf erhalten nun einen Vorteil. Davon profitieren Entwickler und Transaktionen mit minimaler Ressourcennutzung. 

Die überarbeitete Formel lautet:

Priorität = (Priority Fee * angeforderte Compute Units) + Basisgebühr / 

(1 + angeforderte Ausführungs-CUs + Signatur-CUs + Write-Lock-CUs)

Diese neue Berechnung berücksichtigt alle Compute- und Betriebskosten einer Transaktion. Dadurch bilden Prioritätsstufen den tatsächlichen Ressourcenverbrauch korrekt ab. Einfache Token-Übertragungen oder native SOL-Transaktionen ohne zusätzliche Priority Fees erhalten so garantiert eine grundlegende Prioritätsstufe in der Warteschlange. Bei komplexeren Transaktionen sind Entwickler, die mit der Anweisung `SetComputeUnitLimit` kein eigenes CU-Limit angeben, gegenüber Entwicklern mit eigenem Limit bei der Transaktionspriorisierung im Nachteil.

Messung der Effektivität lokaler Gebührenmärkte

In diesem Abschnitt untersuchen wir relevante Daten zu Solanas LFMs. 

Median und Durchschnitt der Transaktionsgebühren

Bei effektiv funktionierenden LFMs sollten die Gebühren für Transaktionen mit nicht umkämpftem Zustand, etwa einfache Stablecoin-Übertragungen, niedrig bleiben. Gleichzeitig sollten die Gebühren für Transaktionen, die auf umkämpften Zustand wie spekulative Token mit geringer Liquidität zugreifen, zusammen mit der Nachfrage stark steigen. Eine hilfreiche Kennzahl für diese Dynamik ist der Vergleich zwischen Median und Durchschnitt der Priority Fees von Transaktionen. Die Median-Gebühr entspricht der Gebühr, die der Nutzer im 50. Perzentil zahlt, und bildet typische Kosten ab. Die Durchschnittsgebühr teilt dagegen alle Gebühren durch die Gesamtzahl der Transaktionen und zeigt allgemeine Trends.

Aktuelle Daten bestätigen dieses erwartete Muster. Im November 2024 erreichte die wirtschaftliche Aktivität auf Solana ihren bisherigen Höchststand. Die durchschnittlichen Gebühren für Non-Vote-Transaktionen stiegen auf ein Allzeithoch von mehr als 0,0003 SOL. Trotzdem blieb der Gebührenmedian stabil bei 0,00000861 SOL und war damit etwa 35-mal niedriger. Anders war es im April 2024: Damals ließ ein ähnlicher Anstieg der wirtschaftlichen Aktivität die Durchschnittsgebühren auf über 0,0002 SOL steigen. Gleichzeitig erhöhte sich der Median auf 0,00001862 SOL und war damit nur etwa 10-mal niedriger. Diese Divergenz zeigt, wie effektiv die Gebührenisolierung typische Nutzer während hoher Nachfrage vor Kostenspitzen schützt und die Nutzererfahrung für nicht spekulative Anwendungsfälle bewahrt.

Bei der Analyse ähnlicher Daten aus einem EVM-basierten Netzwerk ohne LFMs, etwa der von Coinbase betriebenen Ethereum-L2 Base, beobachten wir eine starke Korrelation zwischen Median und Durchschnitt der Transaktionsgebühren. Durchschnitt und Median bewegen sich relativ synchron, weil globale Basisgebühren bei steigender Nachfrage zunehmen. Außerdem ist der Abstand zwischen Median und Durchschnitt deutlich kleiner. Am 5. Dezember 2024 stiegen die durchschnittlichen Transaktionsgebühren auf Base beispielsweise auf 0,1115 US-Dollar. Gleichzeitig erhöhte sich der Median auf 0,0228 US-Dollar und war damit etwa fünfmal niedriger.

Rate rückgängig gemachter Transaktionen

Ein weiterer hilfreicher Trend ist die Rate rückgängig gemachter Transaktionen. Während der hohen wirtschaftlichen Aktivität im April und Mai 2024 berichteten Solana-Nutzer häufig von einer schlechteren Nutzererfahrung, da die Chain unter massivem Spam litt. Der fehlende Determinismus beeinträchtigte die Vorhersehbarkeit und Zuverlässigkeit der Transaktionsausführung. Nutzer fluteten das Netzwerk deshalb mit Transaktions-Spam, um ihre Chancen auf eine schnellere Aufnahme zu erhöhen. 

Searcher reichen häufig Transaktionen für opportunistische Trades ein, ohne die Erfolgswahrscheinlichkeit zu berücksichtigen. Arbitrage-Transaktionen mit unangemessen niedrigen Priority Fees sind dennoch gültig. Das Protokoll verarbeitet sie nach anderen Transaktionen mit höheren Priority Fees. Anschließend werden sie aufgrund der Slippage-Logik wahrscheinlich rückgängig gemacht. 

Rückgängig gemachte Transaktionen erreichten im April 2024 mit 75,7 % aller Non-Vote-Transaktionen ihren Höchststand. Nach der Einführung wichtiger Updates, darunter der zentrale Scheduler von Agave 1.18, sank dieser Anteil deutlich.

Eine Kohortenanalyse von Blockworks Research für die vergangenen sieben Tage (6.–13. Januar 2024) zeigt je nach Aktivitätsniveau unterschiedliche Rückgängigraten. Adressen mit 1–5 täglichen Transaktionen, überwiegend Privatanwender, verzeichnen eine Rate von 1,4 %. Bei 6–50 täglichen Transaktionen steigt sie auf 4,6 %. Adressen mit mehr als 10.000 täglichen Transaktionen erreichen dagegen 66,7 %. Hochaktive Adressen mit mehr als 100.000 täglichen Transaktionen, also Bots, verursachen außerdem 95,2 % aller rückgängig gemachten Transaktionen. Im Dezember 2024 lag die Gesamtrate für alle Non-Vote-Transaktionen bei 41,2 %. Das zeigt, dass ein großer Teil der Rechenressourcen des Netzwerks für die Verarbeitung fehlgeschlagener Arbitragegeschäfte verbraucht wird.

Bestehende Probleme und Verbesserungspotenzial

Trotz deutlicher Fortschritte steht der Scheduler des Agave-Validator-Clients weiterhin vor Herausforderungen. Die folgende Analyse der Thread-Workloads in der Banking Stage durch Anza-Ingenieur Alessandro Decina zeigt bestehende Ineffizienzen und Verbesserungspotenzial.

Scheduler-Thread: Dies ist der wichtigste Thread für die Blockproduktion. Der Scheduler nimmt alle eingehenden Transaktionen entgegen, sortiert sie und plant ihre Ausführung. 

Threads für Vote-Transaktionen: Zwei dedizierte Threads verarbeiten Vote-Transaktionen getrennt von Nutzertransaktionen.

Threads für Non-Vote-Transaktionen: Vier Threads empfangen die vom Scheduler eingeplanten Transaktionen und verarbeiten Nutzertransaktionen.

QUIC-Ingest-Threads: Tokio-Threads steuern die Aufnahme von Transaktionen über das QUIC-Protokoll, wenn der Validator als Leader fungiert. Während der Überlastungsphase Anfang 2024 waren diese Threads ein erheblicher Engpass.

Die obige Visualisierung zeigt: Zu Beginn des ersten Blocks des Leaders führen alle Worker-Threads Transaktionen parallel aus. Diese Parallelität geht jedoch schnell in eine sequenzielle Ausführung über. Konkret verarbeitet nur ein Thread für Non-Vote-Transaktionen, Thread drei, weiterhin Transaktionen. Die übrigen Threads bleiben inaktiv.

Dieses Verhalten deutet auf einen Scheduler-Fehler hin, der den Validator-Client daran hindert, seine volle Kapazität zu nutzen. Deshalb erreicht das System nur einen Bruchteil seines Potenzials. Würde das Problem behoben, könnte der Validator bis zum Vierfachen der aktuellen Last verarbeiten.

Beobachtbarkeit

Den aktuellen Gebühren-APIs für die Vorhersage einer zuverlässigen Transaktionsaufnahme fehlt die nötige Ausgereiftheit für deterministische Ergebnisse. Jeder große RPC-Anbieter bietet eine eigene Priority-Fee-API an, während die zentrale Open-Source-Implementierung der RPC API weiterhin nicht optimal ist. Sie berücksichtigt wichtige Netzwerkdynamiken wie den Einfluss von Jito nicht und liefert deshalb weniger genaue Gebührenschätzungen. 

Helius bietet die RPC-Methode `getPriorityFeeEstimate` an. Sie liefert Gebührenempfehlungen anhand historischer Daten aus globalen Märkten und LFMs. Entwickler können entweder eine serialisierte, signierte Transaktion oder eine Liste der an der Transaktion beteiligten Kontoschlüssel eingeben. Die Methode unterstützt benutzerdefinierte Priority-Fee-Stufen, die in sechs Perzentile eingeteilt sind: Minimum, niedrig, mittel, hoch, sehr hoch und unsicheres Maximum. Die mittlere Stufe, also das 50. Perzentil, ist die Standardempfehlung. Die Gebühren werden anhand der Daten aus den 50 neuesten Slots berechnet.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

Oben: Beispiel-Payload für getPriorityFeeEstimate mit einer Base58-codierten serialisierten Transaktion.

Ohne eine deterministische Methode zur Berechnung von Priority Fees gehen Entwickler oft vorsichtig vor und zahlen zu viel, um die Verarbeitung ihrer Transaktionen zu garantieren. Alternativ verwenden sie übermäßig häufig Jito-Tips, selbst bei Transaktionen, die keine Position am Blockanfang benötigen. Diese Tips dienen häufig als Ersatz für Priority Fees. Bemerkenswert ist, dass die meisten 2024 beobachteten Tips nicht mit traditionellen MEV-Aktivitäten wie Arbitrage oder Sandwiching verbunden sind, sondern eine schnellere Aufnahme von Transaktionen erreichen sollen. Validatoren profitieren von dieser Ineffizienz, indem sie höhere Block-Prämien und MEV-Provisionen erhalten.

Eine weitere Herausforderung entsteht, wenn Entwickler keine Logik implementieren, die ihre Priority Fees dynamisch an schwankende Onchain-Bedingungen anpasst. Bei bedeutenden Ereignissen wie starken Marktbewegungen können die Gebühren für den Zugriff auf bestimmte Zustandskonten drastisch steigen. Anwendungen ohne dynamische Gebührenmechanismen geraten in solchen Szenarien in Schwierigkeiten, da ihre statischen Gebühreneinstellungen keine rechtzeitige Ausführung gewährleisten.

Vorgeschlagene Lösungen

Es wurden verschiedene Strategien vorgeschlagen, um Solanas Gebührenstruktur weiter zu verbessern. Diese Vorschläge sollen die Zuweisung von Netzwerkressourcen optimieren und Anreize für Spam reduzieren.

Exponentielle Write-Lock-Gebühren

SIMD-0110 wurde im Januar 2023 von Tao Zhu (Anza) und Anatoly Yakavenko vorgeschlagen und beschreibt einen neuen Mechanismus zur Überlastungssteuerung durch dynamische Gebühren für umkämpfte Konten. Dieser Mechanismus erfasst den exponentiellen gleitenden Mittelwert (EMA) der Compute-Unit-Auslastung (CU) von schreibgesperrten Konten und erhöht die Kosten für Schreibsperren auf Konten, die dauerhaft stark ausgelastet sind.

Für die Umsetzung eines solchen Systems verwaltet die Solana-Runtime einen LRU-Cache (Least Recently Used) mit öffentlichen Schlüsseln umkämpfter Konten und den zugehörigen Compute Unit Pricern (CUPs). CUPs überwachen die EMA-CU-Auslastung eines Kontos und liefern bei einer Abfrage einen aktualisierten Kostensatz.

Der Mechanismus passt Write-Lock-Gebühren dynamisch an. Überschreitet die EMA-CU-Auslastung eines Kontos einen Zielwert, steigt der Kostensatz für Schreibsperren. Fällt die Auslastung dagegen unter den Zielwert, sinkt der Kostensatz. Die anfänglichen Parameter umfassen:

• Eine Zielauslastung von 25 % des maximalen CU-Limits des Kontos.
• Einen anfänglichen Kostensatz für Schreibsperren von 1.000 Micro-Lamports pro CU.
• Eine Kostenanpassungsrate von 1 % pro Block.

Die Write-Lock-Gebühr für ein Konto wird berechnet, indem sein Kostensatz mit den von der Transaktion angeforderten CUs multipliziert wird. In diesem System setzen sich die gesamten Transaktionsgebühren aus drei Komponenten zusammen: der Basisgebühr für die Signatur, der Priority Fee und der Write-Lock-Gebühr. Write-Lock-Gebühren werden zu 100 % verbrannt.

Bei seiner Veröffentlichung löste SIMD-0110 eine lebhafte Debatte in der Community aus. Der Vorschlag ist derzeit jedoch inaktiv und wurde inzwischen als geschlossen markiert.

Dynamische Basisgebühren

Eine weitere langfristige Lösung zur Verbesserung von Solanas LFM wäre die Einführung globaler und kontospezifischer dynamischer Basisgebühren (DBFs). Jarry Xiao und Eugene Chen von Ellipsis Labs gehören zu den bekannten Befürwortern dieses Ansatzes.

Priority Fees sind optional, Basisgebühren dagegen verpflichtend. Solanas Basisgebühr ist derzeit auf 5.000 Lamports pro Signatur festgelegt. Nutzer einfacher Token-Übertragungen zahlen dieselbe Basisgebühr wie Nutzer komplexer Swaps über mehrere Handelsplätze oder Searcher, die komplizierte MEV-Arbitragegeschäfte ausführen möchten. Basisgebühren bilden die Compute-Nutzung einer Transaktion nicht korrekt ab.

Mit dynamischen Basisgebühren kann eine Arbitrage-Transaktion mit unangemessenen Basisgebühren als ungültig eingestuft und verworfen werden, bevor sie den Scheduler erreicht. Höhere Basisgebühren motivieren Spammer dazu, weniger Transaktionen zu senden.

Basisgebühren erreichen letztlich ein Gleichgewicht. Transaktionen werden dann entsprechend dem Wert auf dem Blockspace-Markt bepreist. Da die Basisgebühr steigt, erreicht sie schließlich die Grenzkosten, bei denen das Senden der Transaktion die Opportunitätskosten des Geschäfts nicht mehr rechtfertigt. Die Gebühren dürfen nicht zu hoch werden, da sonst die Nutzeraktivität beeinträchtigt wird. Ideal ist ein Maximum, das für Bots zu hoch, für Nutzer aber im Allgemeinen akzeptabel ist. In einem solchen System würden Konten, die Transaktionen zur Aufnahme spammen, ihr gesamtes SOL verbrennen.

Solanas schnelle Blockzeiten ermöglichen aggressive Algorithmen zur Festlegung der Basisgebühren. Bei hoher Nachfrage können die Gebühren schnell angepasst und potenziell mit jedem Block verdoppelt werden, um die Netzwerküberlastung abzubilden. Sinkt die Nachfrage, können die Gebühren dagegen schrittweise reduziert werden. Dank Solanas kurzer Blockzeiten erfolgen auch Gebührensenkungen relativ schnell. So passt sich das Netzwerk zügig an veränderte Bedingungen an.

Ein Beispiel für eine ähnliche Form von wirtschaftlichem Gegendruck ist das Metaplex-Candy-Machine-Programm, das 2022 eine Bot-Steuer als Anti-Spam-Mechanismus einführte. Die Bot-Steuer ist eine optionale Gebühr für ungültige Transaktionen. Normalerweise wäre sie relativ niedrig, damit echte Nutzer, denen ein ehrlicher Fehler unterlaufen ist, nicht beeinträchtigt werden. Diese Steuer erwies sich als wirksam: Die Mittel von Mint-Snipern waren schnell aufgebraucht und der Spam endete.

Fazit

Solanas LFMs funktionieren, bieten aber noch erhebliches Verbesserungspotenzial:

• Priority-Fee-Mechanismen verbessern: RPC-Aufrufe für Priority Fees müssen verbessert werden. Im Idealfall sollten Entwickler Gebühren auf einfache, deterministische Weise so festlegen können, dass die Aufnahme einer Transaktion innerhalb der nächsten Blöcke garantiert ist.
• Spam wirtschaftlich unattraktiv machen: Das Netzwerk muss Wege finden, bei hoher wirtschaftlicher Aktivität wirtschaftlichen Gegendruck gegen Bots aufzubauen und gleichzeitig die Gebühren für echte menschliche Nutzer niedrig zu halten.
• Entwickler informieren: Entwickler sollten keine statischen Transaktionsgebühren für Anwendungen mehr festlegen und sich bei Routinetansaktionen weniger auf Mechanismen außerhalb des Protokolls wie Jito verlassen.
• Scheduler weiter optimieren: Der Transaktions-Scheduler muss weiter optimiert werden, damit bei hoher Nachfrage alle Worker-Threads genutzt werden.

Wie Solana-Mitgründer Anatoly Yakovenko betont, sind diese Herausforderungen in erster Linie „nur technische Probleme“ und mit dem richtigen technischen Fokus lösbar.

Weitere Ressourcen

• Solana-Gebühren, Teil 1 - Umbra Research
• Auf dem Weg zu multidimensionalen Solana-Gebühren - Umbra Research
• Lokale Gebührenmärkte sind für die Skalierung von Ethereum notwendig - Eclipse Labs
• Solanas lokale Gebührenmärkte sind nicht real | Eugene Chen - Lightspeed Podcast
• Solana Banking Stage und Scheduler - A.Fitzgerald