Agave-v2.3-Update: Alles, was du wissen musst

Einführung

Die Version 2.3 des Agave-Validator-Clients ist ein weiterer wichtiger Fortschritt für Solana. Wie frühere Updates bringt auch diese neue Version entscheidende Verbesserungen für die Netzwerkleistung und die Developer Experience.

Wichtige Neuerungen in Agave 2.3 

• Neuer TPU-Client tpu-client-next
• Optimierungen an AccountsDB mit weniger Festplatten-I/O
• Leader-Zeitplan basiert jetzt auf den Vote Accounts der Validatoren
• Verifizierung slashbarer Ereignisse
• Greedy Scheduler ist standardmäßig aktiviert
• Verbesserungen an Snapshots
• Verbesserungen an Gossip
• Schnellere Epochenübergänge

Jeder Abschnitt dieses Artikels ist eigenständig. So kannst du direkt zu den Themen springen, die für dich am wichtigsten sind. Ob du einen Validator betreibst, entwickelst oder Solana aktiv nutzt: Dieser umfassende Leitfaden zu Agave 2.3 liefert dir die wichtigsten Erkenntnisse, damit du die neuesten Verbesserungen voll ausschöpfen kannst.

Anza beschleunigt den Release-Zyklus von Agave. Weniger als drei Monate nach 2.2 ist Version 2.3 bereits live. Der neue Client läuft derzeit auf Validatoren mit insgesamt 13 % des Stakes. Die Akzeptanz dürfte in den kommenden Wochen schnell steigen. Während des Rollouts wurden die Aktivierungen von Feature Gates im Mainnet vorübergehend pausiert. Sie werden bald im Rahmen der geplanten Aktivierungssequenz fortgesetzt.

Neuer TPU-Client

Agave 2.3 führt eine neue Implementierung des Clients für die Transaction Processing Unit (TPU) ein, die den bisherigen ConnectionCache ersetzt. Dieser TPU-Client sendet serialisierte Transaktionen über das Netzwerk und das QUIC-Protokoll an Validatoren. Das neue Design heißt tpu-client-next und wurde komplett neu entwickelt. Es verbessert die Leistung deutlich, reduziert den Ressourcenverbrauch und vereinfacht die gesamte Architektur.

Der TPU-Client kommt in zwei Hauptszenarien zum Einsatz: in der ForwardingStage, in der Validatoren Transaktionen an den nächsten Leader weiterleiten, und im SendTransactionService, den RPCs verwenden, um Transaktionen an den Leader zu übermitteln.

Die bisherige Implementierung ConnectionCache unterstützte sowohl UDP als auch QUIC und war dadurch unnötig komplex. ConnectionCache nutzte eine interne asynchrone Warteschlange statt eines expliziten Kanals, um Transaktionen zu speichern. Zudem enthielt die Implementierung eine Logik zum Aufwärmen des Caches, die leere Pakete sendete. Auch bei der Verwaltung von Quinn-Endpunkten – Quinn ist eine Rust-Implementierung von QUIC – traten anhaltende Probleme auf.

Der neue tpu-client-next löst diese Probleme mit einem schlanken, asynchronen Design. Intern folgt er einem agentenbasierten Modell, bei dem einzelne Worker-Tasks jeweils eine QUIC-Verbindung verwalten. Diese Worker kommunizieren über asynchrone Kanäle mit einem zentralen ConnectionWorkersScheduler. 

Wenn der Scheduler einen Transaktions-Batch empfängt, überträgt er ihn gemäß der konfigurierten Strategie an die passenden Worker. Die Architektur verzichtet vollständig auf Multistreaming und reduziert dadurch die Fragmentierung des Datenverkehrs. Verbindungen werden außerdem vorab aufgebaut. Dadurch entfällt die Latenz, die sonst beim Öffnen neuer Streams zum Sendezeitpunkt entsteht.

tpu-client-next erzielt deutliche Leistungssteigerungen. 

• In RPC-Experimenten im Testnet erreichten der alte und der neue Client unter Last einen ähnlichen durchschnittlichen TPS-Wert. tpu-client-next zeigte jedoch deutlich weniger Jitter. 
• Bei Validator-Anwendungsfällen steigerte die ForwardingStage das Volumen weitergeleiteter Transaktionen um 10 %. Gleichzeitig wurde der Datenverkehr stabiler und die CPU-Auslastung sank um 30 %.
• Anzas proprietäres Stresstest-Tool transaction-bench, basiert auf dem neuesten Client. Es erzeugt doppelt so viele Transaktionen pro Sekunde wie das bisherige Benchmark-Tool bench-tps.

tpu-client-next ist vollständig abwärtskompatibel und jetzt die Standardimplementierung für Agave-Nodes. Falls Probleme auftreten, können Betreiber zum bisherigen Verhalten zurückkehren. Dazu starten sie ihren Node mit dem Flag --use-connection-cache, um die alte Implementierung wiederherzustellen.

Zusammengefasst bietet tpu-client-next:

• Eine asynchronitätsfreundliche, agentenbasierte Architektur
• Gleichmäßigen Datenverkehr mit weniger Jitter
• Geringere CPU- und Speicherauslastung
• Konfigurierbare Richtlinien für Scheduling und Warteschlangen
• Einfachere Integration und eine übersichtlichere API-Oberfläche

Leader-Zeitplan auf Basis von Vote Accounts

Im Release-Zyklus von Agave 2.3 aktiviert Solana SIMD-0180: Vote-Account-Adresse als Schlüssel für den Leader-Zeitplan verwenden. Diese Änderung betrifft die Auswahl der Validatoren, die laut Netzwerkplan Blöcke produzieren sollen. Statt der Identitätsadressen der Validatoren dienen künftig die Adressen der Vote Accounts als primärer Schlüssel im Leader-Zeitplan.

Diese Migration beseitigt eine seit Langem bestehende Unklarheit im Solana-Protokoll: Ein blockproduzierender Validator lässt sich bisher nicht zuverlässig einem bestimmten Stake zuordnen. Im aktuellen Design basiert der Leader-Zeitplan auf den Identitätsadressen der Validatoren. Mehrere Vote Accounts können jedoch an dieselbe Validator-Identität delegieren. Dadurch lässt sich die Blockproduktion eines bestimmten Slots nur schwer auf eine konkrete Menge delegierten Stakes zurückführen.

Indem der Leader-Zeitplan stattdessen die Adressen der Vote Accounts als Schlüssel verwendet, entsteht eine klare und direkte Verbindung zwischen delegiertem Stake und der Leader-Rolle des Validators. Diese scheinbar kleine Änderung ermöglicht mehrere wichtige Funktionen.

Erstens schafft sie die notwendige Grundlage für die Verteilung von Block-Belohnungen, wie in SIMD-0123 beschrieben. SIMD-0123 wurde im März durch eine formelle Governance-Abstimmung angenommen. Validatoren können damit einen Provisionssatz für Blockgebühren festlegen und die verbleibenden Einnahmen proportional unter den Delegierenden verteilen. Dieses System entspricht dem bereits für inflationäre Staking-Belohnungen genutzten Modell zur Aufteilung von Belohnungen. So werden die wirtschaftlichen Anreize von Validatoren und ihren Stakern besser aufeinander abgestimmt.

Zweitens sind Vote-Account-Adressen als Schlüssel für den Leader-Zeitplan unerlässlich, um programmatisches Slashing zu ermöglichen. Dabei werden Validatoren bestraft, die gegen Netzwerkregeln verstoßen, indem sie doppelte Blöcke einreichen oder auf mehreren Forks abstimmen. Das führt uns direkt zum nächsten Update.

Verifizierung slashbarer Ereignisse

Slashing ist ein Mechanismus zur Bestrafung böswilliger Validatoren. Dabei wird das Fehlverhalten on-chain verifiziert und ein Teil ihres delegierten Stakes vernichtet. Es ist ein wichtiges Abschreckungsmittel gegen Verhalten, das die Sicherheit oder Stabilität des Netzwerks gefährdet.

Es gibt zwei primäre Slashing-Modelle:

Social Slashing (aktuelles System auf Solana)

Solana setzt derzeit auf einen manuellen, gemeinschaftlich gesteuerten Konsensansatz, der als Social Slashing bezeichnet wird. Verhält sich ein Validator böswillig und gefährdet beispielsweise die Verfügbarkeit oder Sicherheit des Netzwerks, können sich ehrliche Teilnehmer off-chain koordinieren, um einen Hard Fork einzuleiten. Dabei wird das Netzwerk neu gestartet und der Stake des Verursachers gekürzt. Dieses Verfahren ermöglicht zwar flexible Einzelfallentscheidungen, verursacht aber erheblichen Koordinationsaufwand und reagiert erst nach einem Vorfall.

Programmatisches Slashing (Slashing innerhalb des Protokolls)

Programmatisches Slashing wird dagegen vollständig on-chain durchgesetzt. Verstößt ein Validator gegen die Protokollregeln, kann ein kryptografischer Nachweis des Verstoßes an ein spezielles Programm übermittelt werden, das anschließend automatisch das Slashing auslöst. Dieses Modell reduziert die Abhängigkeit von menschlicher Koordination. Es ermöglicht zudem, kleinere Verstöße zu ahnden, ohne den Netzwerkbetrieb zu unterbrechen, und schafft damit die Grundlage für skalierbare, dezentrale Rechenschaftspflicht.

Slashing umfasst zwei zentrale Schritte:

• Fehlererkennung und Zuordnung: das Fehlverhalten und den verantwortlichen Validator identifizieren.
• Durchsetzung der Strafe: den Verursacher wirtschaftlich bestrafen, indem sein Stake gekürzt und er zur Verantwortung gezogen wird.

Im Release-Zyklus von Agave 2.3 soll Solana ein Feature Gate für das Slashing Program aktivieren, wie im SIMD SIMD-0204: Verifizierung slashbarer Ereignisse beschrieben. Dies ist der erste Schritt hin zu programmatischem Slashing auf Solana. Der Schwerpunkt liegt auf der Fehlererkennung und Zuordnung. Das Update führt ein On-Chain-Programm ein, mit dem jeder slashbares Verhalten melden und protokollieren kann. Damit entsteht die Grundlage für eine künftige automatisierte Durchsetzung.

Dieses Programm verändert weder Stakes noch Belohnungen. Es verifiziert und protokolliert ausschließlich Verstöße und dient damit als On-Chain-Protokoll für Fehlverhalten von Validatoren. Ein früher Prototyp des Programms wurde im Testnet bereitgestellt (siehe etwa diese DuplicateBlockProof-Beispieltransaktion). 

Das Programm konzentriert sich zunächst auf das Erkennen und Protokollieren doppelter Blockproduktion. Unterstützung für weitere Verstöße wie doppelte Abstimmungen ist geplant. Entscheidend ist: Programmatisches Slashing beschränkt sich auf eindeutig nachweisbares Fehlverhalten. Subjektivere oder systemische Probleme wie absichtlich langsame Blockproduktion oder MEV-Extraktion lassen sich daher deutlich schwieriger ahnden und werden vom Slashing Program voraussichtlich nicht abgedeckt.

Eingereichte Nachweise enthalten zwei widersprüchliche Shreds für denselben Slot, die beide vom selben Validator signiert wurden. Das Slashing Program verifiziert den Nachweis, indem es prüft, ob die Shreds einen gültigen Nachweis für einen doppelten Block bilden, zum selben Slot gehören und vom verantwortlichen Validator korrekt signiert wurden. Diese Logik entspricht dem Ansatz, den das Gossip-Protokoll von Solana bei der Verarbeitung von Nachweisen für doppelte Blöcke während der Fork-Auswahl verwendet. 

Nach erfolgreicher Verifizierung eines Nachweises werden die Ergebnisse zur späteren Verwendung in einer Program-derived Address (PDA) gespeichert. So lassen sich Dashboards für Slashing-Daten einfach erstellen, indem getProgramAccounts auf dem Slashing Program ausgeführt wird. Validatoren können damit prüfen, ob Verstöße gegen sie gemeldet wurden, und bei Bedarf Korrekturmaßnahmen ergreifen.

Ein künftiges SIMD wird die wirtschaftliche Durchsetzung von Slashing behandeln, einschließlich Parametern wie der Stake-Strafe für verschiedene Verstöße. Da diese Entscheidungen die Wirtschaftlichkeit des Betriebs eines Solana-Validators beeinflussen, müssen alle vorgeschlagenen Änderungen durch eine vollständige Governance-Abstimmung genehmigt werden.

Schnellere Epochenübergänge

Agave 2.3 verbessert die Geschwindigkeit von Epochenübergängen erheblich. Die Berechnung von Epochenbelohnungen dauert jetzt weniger als 500 Millisekunden. Dadurch werden weniger Slots übersprungen und Transaktionen rund um die Epochengrenze zuverlässiger verarbeitet.

Wird der erste Leader-Slot einer neuen Epoche übersprungen, stellt Agave 2.3 außerdem sicher, dass die Belohnungen nicht erneut berechnet werden. Stattdessen verwendet der Client die zuvor berechneten Ergebnisse wieder. Das vermeidet redundante Berechnungen und ermöglicht einen reibungsloseren Start in die neue Epoche.

AccountsDB-Optimierungen

Die Speichereffizienz wurde in diesem Release deutlich verbessert. Die Festplatten-I/O ist um etwa 75 % gesunken und das Volumen der Reparaturanfragen um rund 85 %. Zusammen sorgen diese Optimierungen für eine gleichmäßigere und zuverlässigere Node-Leistung, besonders bei hoher Netzwerklast.

Greedy Scheduler standardmäßig aktiviert

In Agave 2.3 ist der Greedy Scheduler jetzt standardmäßig aktiviert. Der bisherige zentrale Scheduler wurde bei hoher Netzwerklast häufig zum Engpass, weil das Sortieren von Transaktionen und Erstellen eines Abhängigkeitsgraphen viel Zeit beanspruchte. Der neuere Greedy-Ansatz beschleunigt das Transaktions-Scheduling durch eine vereinfachte Logik und kleinere Batch-Größen erheblich.

Weitere Informationen zum Greedy Scheduler findest du in unserem früheren Helius-Blogbeitrag.

Gossip-Shred-Version

Agave 2.3 setzt übereinstimmende Shred-Versionen im Gossip-Netzwerk strenger durch. Nodes dürfen eingehende Gossip-Verbindungen jetzt nur herstellen, wenn ihre Shred-Version mit der des Clusters übereinstimmt. So werden falsch konfigurierte Nodes frühzeitig abgewiesen.

Bisher konnten Spy-Nodes dem Netzwerk beitreten, ohne dass ihre Shred-Version mit der des Clusters übereinstimmte. Mit dieser Änderung müssen alle Nodes, einschließlich Nodes im Spy-Modus, die richtige Shred-Version beziehen – entweder von einem Cluster-Einstiegspunkt oder durch explizites Festlegen über die Befehlszeile.

Dieses Update baut auf jüngsten Maßnahmen zur Reduzierung des Gossip-Overheads auf. In den vergangenen Monaten ist der eingehende Gossip-Datenverkehr um etwa 61 % gesunken. Möglich wurde dies durch die Einstellung von drei Gossip-Nachrichtentypen und die Abschaffung der Werbung für Epochen-Slots durch Validatoren ohne Stake.

RPC-Simulationen enthalten die Ressourcennutzung

Um die Ressourcennutzung von Transaktionen transparenter zu machen, wurde der standardmäßigen RPC-Methode `simulateTransaction` ein neues Feld hinzugefügt: `loadedAccountsDataSize`. Dieses Feld gibt die Gesamtzahl der Bytes an Account-Daten an, die während der Simulation geladen wurden.

Damit können Entwickler Transaktionskosten genauer schätzen und Priority Fees präziser abstimmen. Das Laden von Account-Daten verbraucht Compute Units (CUs) – 8 CUs pro 32 KB, basierend auf der Größe der Heap-Page-Zuweisung von Solana. Diese Metrik hilft Entwicklern, beim Erstellen und Senden von Transaktionen besser auf Kosteneffizienz zu optimieren.

Snapshot-Verbesserungen

Snapshots dienen als regelmäßige Speicherpunkte, mit denen Nodes ihren Zustand wiederherstellen können. Nodes erstellen diese Snapshots kontinuierlich und ersetzen ältere Versionen im Laufe der Zeit durch neuere.

Dieses Release verbessert die Nutzung von Snapshots in mehreren Punkten:

• Standardintervall aktualisiert: Das Standardintervall für vollständige Snapshots wurde von 25.000 auf 50.000 Slots erhöht. Dadurch werden Snapshots seltener erstellt.
• Neues Flag zum Deaktivieren von Snapshots: Mit dem neuen Flag `--no-snapshots` lässt sich die Snapshot-Erstellung explizit deaktivieren. Die bisherige Methode mit `--snapshot-interval-slots 0` ist jetzt veraltet.
• Verbessertes Geyser-Verhalten: Bei der Wiederherstellung aus einem Snapshot werden über Geyser gesendete Account-Benachrichtigungen nicht mehr dedupliziert.

Ein weiterer Vorteil des längeren Snapshot-Intervalls ist eine gleichmäßigere Festplattenleistung mit weniger IOPS-Spitzen (Ein-/Ausgabevorgänge pro Sekunde).

Verbesserungen an der SBPF-Toolchain

Agave 2.3 bringt mehrere Verbesserungen für Entwickler, die mit der SBPF-Toolchain arbeiten:

• Gezielte Versionsauswahl: Entwickler können beim Kompilieren von Programmen jetzt explizit bestimmte BPF-VM-Versionen (v0–v3) auswählen und erhalten dadurch mehr Kontrolle.
• Ab SBPFv3 nur noch Rust: Ab SBPFv3 wird nur noch die Rust-basierte Toolchain unterstützt. Die ältere C-Toolchain ist mit künftigen Versionen nicht mehr kompatibel.
• Neues Optimierungs-Flag: Das neue Build-Flag `--optimize-size` erzeugt kleinere Programmbinärdateien für die Bereitstellung. Dadurch lässt sich Speicherplatz sparen, allerdings kann die Nutzung von Compute Units (CU) leicht steigen.

Weitere Änderungen

Dieses Release enthält außerdem folgende Updates:

• Automatische Cluster-Wiederherstellung: Die neue Funktion `wen-restart` startet einen Cluster nach einem Chain-Absturz automatisch neu.
• Aktualisierte Logging-ABI: Die Logging-ABI `TimedTracedEvent` enthält jetzt neue Diagnosedaten. Validatoren müssen deshalb alle externen Tracing- oder Analysetools aktualisieren, die diese Logs verwenden, um die Kompatibilität sicherzustellen. Vorhandene Trace-Daten sollten nach dem Upgrade gelöscht werden, um nicht übereinstimmende Formate zu vermeiden.
• CLI-Verbesserungen: withdraw-stake AVAILABLE wurde hinzugefügt, um das Abheben aller nicht gestakten Lamports zu vereinfachen. Zudem bindet solana-test-validator RPC-Dienste für mehr Sicherheit jetzt standardmäßig an localhost (127.0.0.1).
• Schnellerer Start: Die Startzeiten von Validatoren wurden deutlich reduziert. Nodes benötigen jetzt etwa 3 Minuten, um zu starten und das Ledger zu laden, sowie ungefähr 5 Minuten, um den aktuellen Stand der Chain zu erreichen. Fastboot erfordert nun jedoch ein ordnungsgemäßes Herunterfahren mit dem neuen Flag --wait-for-exit. Betreiber müssen warten, bis sich der Validator-Prozess vollständig selbst beendet hat, bevor sie ihn neu starten, statt sofort einen Neustartbefehl auszuführen.

Fazit

Agave 2.3 ist ein weiterer wichtiger Meilenstein für das Solana-Protokoll. Zu den Highlights gehören der neue TPU-Client (`tpu-client-next`), deutlich weniger Festplatten-I/O durch AccountsDB-Optimierungen, eine bessere Snapshot-Leistung, Verbesserungen am Gossip-Netzwerk sowie schnellere Epochenübergänge und Startzeiten. Zusammen machen diese Updates das Netzwerk robuster und verbessern die Erfahrung für Entwickler und Validator-Betreiber.

Solana macht weiter stetige Fortschritte auf dem Weg zu einem robusten Multi-Client-Netzwerk. Firedancer läuft bereits auf Validatoren mit mehr als 8 % des gesamten Stakes – Tendenz steigend. Fast eineinhalb Jahre unterbrechungsfreier Betrieb zeigen, wie ausgereift und stabil die Kernsoftware des Netzwerks inzwischen ist. Gleichzeitig steigt das Tempo bei Major- und Minor-Releases.

Als Nächstes: Agave 3.0!

Weitere Ressourcen

• Release-Zeitplan für Agave 2.3
• Änderungsprotokoll für Agave 2.3
• Pull Requests für Agave 2.3
• Patch Notes für Agave 2.3 – Anza-Blog 
• Präsentation zu tpu-client-next – Solana Core Community Call, 20. Juni 2025