Agave-3.0-Update: Alles, was du wissen musst

Einführung

Das Major-Release Agave v3.0 ist ein weiterer Meilenstein für Solana. Es bringt zahlreiche Verbesserungen für Netzwerk-Performance, Validator-Betrieb und Developer Experience.

Wichtige Neuerungen in Agave 3.0 

• Überarbeiteter Cache: beschleunigt die Transaktionsverarbeitung um 30–40 %
• Höheres Compute-Limit für einzelne Accounts: erhöht das Limit pro Account auf 40 % der CUs eines Blocks
• Neue TransactionView-Struktur für den Scheduler: verbessert die Scheduling-Effizienz
• eXpress Data Path (XDP) für Turbine: eine Voraussetzung für Blöcke mit 100 Millionen CUs
• Höhere CPI-Verschachtelungstiefe: erhöht das CPI-Verschachtelungslimit von 4 auf 8
• Gelockerte Entry-Beschränkungen: vereinfacht die Scheduling-Logik und ist für die asynchrone Ausführung erforderlich
• Kürzere Startzeiten: Nodes sind jetzt schneller wieder online
• Spezifikation für die Größe geladener Transaktionsdaten: standardisiert die Berechnung geladener Transaktionsdaten
• RPC-Verbesserungen: schnellere und zuverlässigere Echtzeit-Updates für dApps mit PubSub WebSockets

Jeder Abschnitt dieses Artikels ist eigenständig. So kannst du dich auf die Themen konzentrieren, die für dich am wichtigsten sind. Ob du Validatoren betreibst, entwickelst oder aktiv zur Community beiträgst: Dieser Leitfaden zu Agave v3.0 liefert dir die wichtigsten Neuerungen und Erkenntnisse, damit du die aktuellen Verbesserungen optimal nutzen kannst.

Client-bezogene Trends

Bevor wir uns die neuen Funktionen von Agave v3.0 im Detail ansehen, betrachten wir aktuelle Daten zur Entwicklung des Solana-Netzwerks und des Agave-Clients. Sie zeigen schnellere Release-Zyklen, eine breitere Client-Verbreitung und eine robuste Performance unter hoher Last.

Release-Rhythmus von Agave

Anza hat seinen Release-Rhythmus dieses Jahr deutlich beschleunigt und den Abstand zwischen kleineren Agave-Versionen auf weniger als drei Monate verkürzt. Die Agave-2.2.*-Reihe blieb nur 11 Wochen lang die Supermajority-Version. Agave 2.3 folgt einem ähnlichen Zeitplan.

Multi-Client-Netzwerk

Die Verbreitung von Firedancer im Mainnet ist in den vergangenen Monaten deutlich gestiegen. Derzeit laufen 21,6 % des Stakes über den Jito-Frankendancer-Client. Dieser Anteil ist im Jahresverlauf langsam und stetig gewachsen (siehe Diagramm unten). Die Verbreitung dürfte bei etwa 20 % bleiben, bis der vollständige Firedancer-Client produktionsreif für den Einsatz im Mainnet ist.

Dies ist ein wichtiger Meilenstein für Solanas Multi-Client-Strategie. Ihr langfristiges Ziel ist es, Sicherheit, Verfügbarkeit und Resilienz des Netzwerks zu verbessern. Eine größere Client-Vielfalt bietet Validator-Betreibern mehr Auswahl, fördert einen gesunden Wettbewerb zwischen den Client-Teams und sorgt dafür, dass mehr Personen die Client-Codebasen prüfen. Außerdem sinkt das Risiko, dass ein einzelner kritischer Fehler einen netzwerkweiten Ausfall auslöst.

Bemerkenswert ist auch, dass der Stake auf dem unveränderten Agave-Client – also Agave ohne MEV-Modifikationen von Drittanbietern wie Jito – von rund 6 % zu Jahresbeginn auf heute etwa 2 % gesunken ist. Gleichzeitig ist die Verbreitung von Paladin-Agave in den vergangenen Monaten gestiegen. Der Client macht inzwischen etwa 6 % des gesamten Stakes aus.

Netzwerk-Stresstest

Am 10. Oktober erlebte der Kryptomarkt das größte Liquidationsereignis seiner Geschichte. Dies löste auf allen großen Blockchains extreme Volatilität aus. Trotz des rekordverdächtigen Anstiegs der Netzwerkaktivität bewiesen das Solana-Netzwerk und der Agave-Validator-Client unter hoher Last bemerkenswerte Resilienz und Stabilität.

Auf dem Höhepunkt bewältigte Solana das Sechsfache seines normalen Datenverkehrs. Leader nahmen dabei rund 100.000 Transaktionspakete pro Sekunde auf, während sie vollständige Blöcke bis zum Limit von 60 Millionen CUs produzierten.

Selbst unter diesen Bedingungen zeigte Solana unter allen großen Netzwerken die stabilste Gebührenentwicklung und verarbeitete gleichzeitig einen um eine Größenordnung höheren Durchsatz. Die tatsächlichen TPS ohne Vote-Transaktionen lagen auf dem Höhepunkt der Aktivität über 3.200.

Während des etwa zweistündigen Spitzenzeitraums stieg die mediane Transaktionsgebühr (P50) bei Solana lediglich auf 0,007 $, also auf weniger als einen Cent. Die durchschnittlichen Gebühren erreichten kurzzeitig 0,10 $, während die obersten 1 % der Transaktionen (P99) knapp über 1,00 $ lagen. Dieses Muster zeigt die Wirksamkeit lokaler Gebührenmärkte. Hohe Gebühren beschränkten sich auf Transaktionen, die mit stark umkämpften Hot Accounts interagierten. Normale Nutzer, die einfache Überweisungen ausführten, etwa Stablecoin-Zahlungen, waren nicht betroffen.

Zum Vergleich: Im Ethereum-Mainnet und bei Arbitrum stiegen die medianen Gebühren im selben Zeitraum kurzzeitig auf über 100 $ pro Transaktion. Auch bei der von Coinbase betriebenen L2 Base schossen die Gebühren in die Höhe. Der Median erreichte mehr als 3 $. Diesen Netzwerken fehlen lokale Gebührenmärkte. Stattdessen passen sie Gebühren global an und erhöhen die Kosten bei hoher Netzwerklast gleichmäßig für alle Nutzer.

Wachstum des Zustands

Solana hat beim Wachstum seines Onchain-Zustands kürzlich einen wichtigen Meilenstein überschritten: Insgesamt gibt es nun mehr als 1 Milliarde Accounts. Fast 67 % dieser Accounts gehören dem Token Program. Davon sind 89,45 % Associated Token Accounts und 10,55 % Token-Mint-Accounts.

Dieses stetige Wachstum des Zustands hat langfristige Folgen für Solana-Clients und Infrastrukturanbieter. Mit der Anzahl der Accounts steigen auch die Anforderungen an Speicher, Snapshot-Größe und Account-Indexierung. All das kann sich auf Performance und Hardwareanforderungen auswirken. Lösungen wie ZK Compression bieten langfristig einen vielversprechenden Weg, um das Aufblähen des Zustands zu reduzieren.

Neuerungen im Release-Zyklus von Agave 3.0

Überarbeiteter Cache

Agave 3.0 reduziert redundante Runtime-Operationen erheblich. Eine vollständige Überarbeitung des Programm-Caches beseitigt Hunderte unnötiger Account-Lookups pro Transaktions-Batch. In internen Benchmarks beschleunigt dies die Transaktionsverarbeitung um etwa 30–40 %.

Account-Limit auf 40 % der Block-CUs erhöhen

Im Release-Zyklus von Agave 3.0 aktiviert Solana SIMD-0306: Account-CU-Limits erhöhen. Dadurch steigt das CU-Limit pro Account von einer statischen Konstante von 12 Millionen auf 40 % des CU-Limits eines Blocks. Derzeit kann jeder Account pro Block bis zu 12 Millionen CUs verbrauchen. Wie das folgende Diagramm von Anza zeigt, erreichen die am stärksten umkämpften Accounts diese Grenze häufig.

Mit dieser Änderung steigt das Limit pro Account zunächst von 12 Millionen auf 24 Millionen CUs. Sobald SIMD-0286 (Blöcke mit 100 Millionen CUs) aktiviert ist, steigt es schließlich auf 40 Millionen CUs. Zusammen mit Neuerungen wie der Einführung des P-token program erhöht dieses Upgrade den Durchsatz für Hot Accounts deutlich, auf die in jedem Block häufig zugegriffen wird.

Andere Beschränkungen bleiben unverändert, darunter:

• Maximale Vote-Einheiten: Obergrenze für die gesamten CUs von Vote-Transaktionen pro Block bei 36 Millionen CUs
• Maximale Änderung der Account-Datengröße pro Block: Obergrenze für die gesamten Änderungen an Account-Daten pro Block bei 100 Megabyte.

Ein höheres CU-Limit pro Account verbessert zwar den Durchsatz für stark genutzten Zustand, kann aber auch die maximale serialisierte Ausführungszeit erhöhen. In Szenarien mit hoher Last könnten dadurch die Blockverifizierung oder die Slot-Dauer länger werden.

Erwähnenswert ist schließlich der aktuelle Vorschlag SIMD-0370: Block-Limit für Compute Units entfernen. Er untersucht, ob sich CU-basierte Block-Limits vollständig abschaffen lassen. Nach dem Alpenglow-Upgrade wird dieses Thema wahrscheinlich erneut aufgegriffen.

eXpress Data Path (XDP) für Turbine

eXpress Data Path (XDP) ist eine Linux-Kernel-Technologie für leistungsfähige Netzwerke. Anwendungen können damit einen Großteil der standardmäßigen Paketverarbeitung des Kernels umgehen. Das reduziert sowohl zwischengeschaltete Datenkopien als auch Kontextwechsel zwischen User Space und Kernel Space. Da XDP Pakete direkt mit der Netzwerkschnittstellenkarte (NIC) im User Space verarbeitet, sinkt der Overhead pro Paket drastisch.

Die Unterstützung für XDP in Turbine wurde erstmals mit Agave v2.3.8 eingeführt und ist ab Agave 3.1 standardmäßig aktiviert. Wenn die Block-Limits auf 100 Millionen CUs steigen, ist Turbine der wichtigste Skalierungsengpass. Leader leiten ihre Shreds an 200 Peers weiter und erzeugen dadurch eine hohe Netzwerklast. Große Validatoren mit mehr Leader-Slots können unter aktuellen Bedingungen fast 150.000 ausgehende Pakete pro Sekunde erreichen. XDP behebt diesen Engpass direkt und beschleunigt den Paketversand um das bis zu 100-Fache. Dadurch können Validatoren größere Blöcke wesentlich effizienter weiterleiten. 

Wenn du tiefer in die XDP-Implementierung in Agave einsteigen möchtest, findest du weitere Informationen im Leitfaden zur Validator-Einrichtung und in unserem früheren Interview mit Anza-Engineer Alessandro Decina, der die Integration von XDP in den Agave-Client leitete.

Spezifikation für die Größe geladener Transaktionsdaten

Im Rahmen der laufenden Arbeiten zur Vereinfachung und Standardisierung des Ausführungsmodells von Solana soll SIMD-0186: Spezifikation für die Größe geladener Transaktionsdaten während des Release-Zyklus von Agave 3.0 im Mainnet aktiviert werden.

Die Spezifikation führt eine konsenssichere Methode ein, um die gesamten von einer Transaktion geladenen Account-Daten zu berechnen. So sollen alle Validator-Clients identische Größen für Transaktionsdaten berechnen. Dadurch entfallen subtile Abweichungen, die sonst zu einem Auseinanderlaufen des Konsenses führen könnten.

Derzeit ist Solanas Logik zur Größenberechnung von Transaktionsdaten übermäßig komplex. Die bestehende Implementierung behandelt LoaderV3 und Programme des BPF Upgradeable Loader auf ungewöhnliche Weise. Bei beiden wird die tatsächliche Größe geladener Programmdaten häufig unterschätzt. Diese Abweichungen erschwerten es unabhängigen Client-Teams, kompatible Logik zu implementieren.

Mit SIMD-0186 sind die Regeln zur Größenberechnung jetzt eindeutig und leicht nachvollziehbar:

• Jeder geladene Account wird genau einmal gezählt
• Programme, die den BPF Upgradeable Loader verwenden, beziehen ihre zugehörigen Programmdaten ein
• Die Größe jedes geladenen Accounts entspricht der Byte-Länge seiner Daten vor der Transaktionsausführung, zuzüglich 64 Byte für Metadaten
• Address Lookup Tables (ALTs) addieren jeweils pauschal 8.248 Byte

Diese Spezifikation standardisiert die Größenberechnung von Transaktionen über alle Clients hinweg und macht das Verhalten von Transaktionen für Entwickler besser vorhersehbar.

Das Limit für die Größe geladener Daten erfüllt eine ähnliche Funktion wie das CU-Limit pro Transaktion. Es sorgt für eine vorhersehbare Ressourcenberechnung auf Validator-Nodes. Standardmäßig kann jede Transaktion bis zu 64 MB Account-Daten laden. Pro 32 KB geladener Daten werden acht Compute Units (CUs) verbraucht. Das entspricht Basiskosten von 16.000 CUs, selbst wenn tatsächlich weniger Daten geladen werden. Entwickler können dieses Limit über die Anweisung setLoadedAccountsDataSizeLimit senken, um Compute-Kosten zu reduzieren und die Scheduling-Effizienz zu verbessern.

Da die neue Berechnungsmethode je nach Transaktionsstruktur unterschiedliche Werte liefern kann, müssen Entwickler möglicherweise das in ihren Compute-Budget-Anweisungen festgelegte Größenlimit für geladene Account-Daten anpassen.

TransactionView-Struktur des Schedulers

Mit Agave 3.0 führt der Scheduler eine neue leichtgewichtige Datenstruktur namens TransactionView ein. Sie optimiert das Parsen und Verarbeiten von Transaktionen. Anders als ältere SDK-Transaktionstypen, die Deserialisierung und mehrere Speicherzuweisungen erforderten, bietet TransactionView eine direkte Ansicht einer serialisierten Transaktion. Die Struktur parst und cached Metadaten zum Aufbau der Transaktion, ohne sie tatsächlich zu deserialisieren.

Kürzere Startzeiten

Mit Agave v3.0 verbessert sich die Start-Performance des Clients weiter. Das erleichtert den Alltag von Validator- und RPC-Betreibern spürbar. Egal, ob ein Neustart nach einem Absturz, einem Upgrade oder planmäßigen Wartungsarbeiten erfolgt: Nodes sind jetzt deutlich schneller wieder online.

Beim Start aus einem Snapshot-Archiv sank die Startzeit auf weniger als dreieinhalb Minuten. Das ist weniger als die Hälfte der unter Agave v2.2 benötigten Zeit (siehe Diagramm unten). Diese Verbesserung ist ein entscheidender Performance-Gewinn. Schnellere Starts erhöhen direkt die Netzwerkresilienz und Verfügbarkeit der Validatoren, da Nodes dem Konsens schneller wieder beitreten können.

Agave v3.1 wird diesen Prozess weiter optimieren. Die Überprüfung von Accounts im Hintergrund entfällt, sodass Validatoren sofort nach Beginn des Replays abstimmen können.

CPI-Verschachtelungslimit erhöhen

SIMD-0268: CPI-Verschachtelungslimit erhöhen erhöht die maximale Tiefe von Cross-Program-Invocation-Aufrufen (CPI) von 4 auf 8. Dadurch verdoppelt sich praktisch die Anzahl der Aufrufe anderer Programme, die ein Solana-Programm innerhalb einer einzelnen Transaktion ausführen kann.

CPI ist der Mechanismus, über den ein Solana-Programm ein anderes aufruft. Diese grundlegende Funktion der Solana-Runtime ermöglicht es Programmen, auf der Logik anderer Programme aufzubauen.

Komplexe Onchain-Protokolle wie Perpetual Swaps, Smart Wallets und Cross-Margin-Systeme nutzen häufig mehrere Ebenen von Programminteraktionen, um Positionen, Liquidationen und Risiken zu verwalten. Das bisherige CPI-Limit von 4 Ebenen schränkte diese Designs ein. Teilweise mussten Entwickler die Logik deshalb auf mehrere Transaktionen verteilen.

Bestehende Anwendungen funktionieren weiterhin wie bisher, sofern ihre Logik nicht auf dem alten Limit beruht, um Transaktionen fehlschlagen zu lassen. Insgesamt erweitert diese häufig gewünschte Änderung den Gestaltungsspielraum für Entwickler und stärkt die Komponierbarkeit von Solana.

Gelockerte Entry-Beschränkungen

SIMD-0083: Entry-Beschränkungen lockern soll während Agave 3.0 aktiviert werden. Die Änderung entfernt die Regel, nach der Transaktionen innerhalb eines Block-Entry nicht miteinander in Konflikt stehen dürfen. Zuvor machte ein Entry mit konfliktbehafteten Transaktionen den gesamten Block ungültig. Das betraf etwa Transaktionen, die beide in denselben Account schreiben oder bei denen eine liest, während eine andere schreibt.

Mit diesem Update sind solche Konflikte erlaubt. Wenn sie auftreten, werden die Transaktionen einfach nacheinander in der angegebenen Reihenfolge ausgeführt. Diese Änderung vereinfacht die Regeln für das Packen von Blöcken. Leader erhalten mehr Flexibilität bei der Reihenfolge von Transaktionen und beim Aufbau von Blöcken. Sie ist außerdem notwendig, damit Solana asynchrone Ausführung implementieren kann.

RPC-Verbesserungen

Agave v3.0 verbessert die Reaktionsfähigkeit des Subscription-Servers. Dieser priorisiert jetzt eingehende Nachrichten wie Subscription-Anfragen und PINGs gegenüber ausgehenden Benachrichtigungen. Dadurch erhalten dApps mit PubSub WebSockets schnellere und zuverlässigere Echtzeit-Updates.

Außerdem wurden den Fehlerdaten für Epoch-Rewards Slot-Eigenschaften hinzugefügt. Das verbessert Debugging und Observability für Entwickler.

Weitere Änderungen

• Seit Agave v3.0.0 veröffentlicht Anza keine vorkompilierten agave-validator-Binärdateien mehr. Validator-Betreiber müssen die Binärdateien jetzt aus dem Quellcode kompilieren und dabei den bereitgestellten Build-Anweisungen folgen.
• Mit Agave v3.0 wurde das standardmäßige Snapshot-Intervall auf 100.000 Slots erweitert. In v2.3 waren es 50.000, in v2.2 noch 25.000. Das längere Intervall verbessert die Festplatten-Performance erheblich und reduziert IOPS-Spitzen (Ein-/Ausgabeoperationen pro Sekunde) beim Erstellen von Snapshots.
• Zahlreiche veraltete CLI-Argumente und Flags wurden entfernt (vollständige Liste).
• Derzeit kann eine Advance-Nonce-Anweisung in einer Transaktion jeden Account der Transaktion als den zu aktualisierenden Account angeben. Nach Aktivierung des Feature Gates für SIMD-0242: Nur statischer Nonce-Account kann die Advance-Nonce-Anweisung nur noch einen statisch eingebundenen Account aktualisieren.

Fazit

Agave v3.0 ist ein umfangreiches Client-Upgrade. Es bringt schnellere Transaktionsverarbeitung, höhere Compute-Limits, effizienteres Scheduling sowie zahlreiche Optimierungen für Validatoren und RPC. Zusammen stärken diese Neuerungen sowohl die Netzwerk-Performance als auch die Developer Experience.

Aktuelle Daten bestätigen diesen Fortschritt: schnellere Release-Zyklen, wachsende Client-Vielfalt und außergewöhnliche Netzwerkstabilität bei Spitzenauslastung zeigen, wie Solana reift. Mit Agave 3.0 als Grundlage des Netzwerks beweist Solana weiterhin seine Skalierbarkeit.

Weitere Ressourcen

• Release-Zeitplan für Agave 3.0
• Zeitplan des Feature-Gate-Trackers
• Änderungsprotokoll für Agave 3.0
• Pull Requests für Agave 3.0