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

Einführung

Mit Agave 4.0 macht der zentrale Validator-Client von Solana einen weiteren Schritt nach vorn. Er verbessert zentrale Performance-Pfade und bereitet das Netzwerk zugleich auf größere Blöcke und das mit Spannung erwartete Alpenglow-Konsensupdate vor.

Wichtige Neuerungen im Release-Zyklus von Agave 4.0

• XDP beschleunigt die erneute Übertragung durch Turbine erheblich
• Replay Stage mit geringerer Latenz
• Vorbereitung auf Alpenglow: Marker für schnelle Leader-Übergaben und Validierung verketteter Block-IDs*
• Erweiterte kryptografische Unterstützung: G2-Arithmetik und BLS12-381-Syscalls*
• Verbesserte Serialisierung mit Wincode
• Höhere Mindestdelegation für Stake mit Stake Program v5*
• Reaktivierung des ZK ElGamal Proof Program*
• Unterstützung für SBPFv3-Programme*

* über Feature Gates gesteuerte Upgrades

Ob du einen Validator betreibst oder entwickelst: Dieser Leitfaden liefert dir die nötigen Updates und Einblicke, damit du die neuesten Verbesserungen optimal nutzen kannst. Jeder Abschnitt dieses Artikels ist eigenständig, sodass du dich auf die für dich relevantesten Themen konzentrieren kannst. 

Zum Zeitpunkt der Veröffentlichung gilt Agave v4.0.0-rc.0 als Mainnet Upgrade Candidate (MUC). Anza sucht Freiwillige, um das Release auf 25 % des Stakes zu bringen. Validator-Betreiber: Jetzt ist Zeit für das Upgrade!

XDP ist bereit für eine breitere Einführung

XDP (kurz für eXpress Data Path) ist der hochperformante Netzwerkpfad, mit dem Agave Turbine beschleunigt. Damit kann Agave ein eBPF-Programm nahe an der Netzwerkkarte laden. So kann der Shred-Traffic einen Großteil der standardmäßigen Linux-Paketverarbeitung umgehen.

Das ist wichtig, weil Turbine zum zentralen Engpass wird, wenn Solana höhere Blocklimits anstrebt. Leader müssen Shreds an Hunderte Peers verteilen. Große Validatoren erreichen unter den aktuellen Bedingungen bereits fast 150.000 ausgehende Pakete pro Sekunde. Während sich das Netzwerk dem langjährigen Ziel von Blöcken mit 100 Millionen CU nähert, müssen Paketversand und erneute Übertragung mit dem Ausführungsdurchsatz skalieren. XDP schafft diesen Spielraum, indem es die Blockverteilung enorm beschleunigt.

Mit Agave 4.0 ist XDP jetzt für den breiteren Einsatz durch Validatoren bereit. Es wurde mit verschiedenen Konfigurationen unter Last getestet, weiter gehärtet und beim Routing zusätzlich verbessert. Die Produktionsergebnisse sind äußerst vielversprechend: Die erneute Übertragung durch Turbine ist um Größenordnungen schneller.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

22. Apr. 2026, 5:25 AM

Weitere Hintergründe dazu, warum XDP eine so bedeutende Verbesserung ist, findest du in unserem früheren Interview mit Anza-Ingenieur Alessandro Decina.

Schnellere Replay Stage

Agave 4.0 beschleunigt Replay, indem es zwei aufwendige Verifizierungsschritte aus dem kritischen Pfad der Replay-Threads verlagert. In v4.0 werden sowohl die Entry-Verifizierung als auch die Verifizierung von Transaktionssignaturen asynchron ausgeführt. Replay kann dadurch weiterarbeiten, während Hintergrundjobs bestätigen, dass der Slot gültig ist.

Die erste Änderung verlagert die Verifizierung von PoH-Entries in den Hintergrund. Zuvor verifizierte Replay zunächst inline die Hash-Kette der Entries. Eine zweite Änderung wendet dasselbe Prinzip auf Transaktionssignaturen an, allerdings mit einer wichtigen Trennung: Agave trennt jetzt die Verifizierung von Transaktions-Hashes und -Nachrichten von der Verifizierung der Ed25519-Signaturen. Der Hash-Pfad wird weiterhin vorab ausgeführt, damit Transaktionen sicher bereinigt und ausgeführt werden können. Die aufwendigeren Signaturprüfungen laufen dagegen im Hintergrund und werden abgeschlossen, bevor der Block akzeptiert wird.

In der Praxis wird die Replay Stage dadurch deutlich seltener blockiert. Das gilt besonders für ausgelastete Slots, in denen die Anzahl der Signaturprüfungen mit der Zahl der Transaktionen steigt.

Breiterer Einsatz von Wincode

Wincode ist eine von Anza entwickelte Bibliothek für Serialisierung und Deserialisierung. Sie ist für direkte Initialisierung und direkte Speicherschreibvorgänge ausgelegt, um Zwischenpuffer zu minimieren. Sie bietet Spitzenperformance unter den Rust-Serialisierern und bleibt vollständig mit dem verbreiteteren bincode kompatibel.

In Agave 4.0 werden weitere performancekritische Serialisierungspfade von bincode auf wincode umgestellt. Da fast alle Daten, die Solana auf Festplatten schreibt oder über das Netzwerk sendet, auf bincode basieren, hat die Optimierung dieser Pfade weitreichende Auswirkungen.

Höhere Mindestdelegation für Stake (Stake Program v5)

Mit Agave 4.0 kommt ein bedeutendes Update für das Stake Program. Diese über ein Feature Gate gesteuerte und in SIMD-0490 beschriebene Änderung bereitet Solanas umfassendere Initiative zur Senkung der Stake Bonds (auch als Rent bezeichnet) vor.

Die wichtigste Änderung: Die Mindestdelegation für Stake steigt von 1 Lamport auf 1 SOL. Damit wird verhindert, dass die Kosten für das Erstellen und Verwalten von Stake-Accounts bei sinkenden Rent-Anforderungen zu niedrig werden, was einen potenziellen Angriffsvektor schaffen könnte. Es gibt zwar viele kleinere Stake-Accounts unterhalb dieses Schwellenwerts, sie machen jedoch nur 0,02 % des gesamten aktiven Stakes aus. Sobald das Update live geht, genießen sie Bestandsschutz.

Das Upgrade bereinigt außerdem mehrere Bereiche der Verwaltung von Stake-Accounts. Rent-Berechnungen verwenden künftig die Rent-Sysvar, statt sich auf die in jedem Account gespeicherte rent_exempt_reserve zu stützen. Außerdem werden Sysvar-Account-Eingaben für Operationen des Stake Program optional und die Split-Implementierung wird neu geschrieben, um langjährige Sonderfälle zu beheben. 

Die Community der Validator-Betreiber unterstützt das neue Minimum von 1 SOL. Tools und dApps, die mit dem Stake Program interagieren, müssen ihre Logik prüfen und das neue Minimum berücksichtigen.

Verbesserte kryptografische Unterstützung 

Mehrere Feature-Aktivierungen im Release-Zyklus von Agave 4.0 sollen Solanas native kryptografische Funktionen erweitern. Damit verbessert sich die Unterstützung moderner Anwendungsfälle, darunter ZK-Proofs und BLS-Signaturen.

Reaktivierung des ZK ElGamal Proof Program

Das ZK ElGamal Proof Program ist ein natives Solana-Programm, das Zero-Knowledge-Proofs für vertrauliche Transfers mit Token-2022 verifiziert. So lassen sich verschlüsselte Salden und Transaktionen validieren, ohne die zugrunde liegenden Daten offenzulegen. Es dient als allgemeiner Verifizierer für kryptografische ElGamal-Proofs und ist ein zentraler Bestandteil der datenschutzfreundlichen Token-Funktionen von Solana. 

Das Programm wurde nach einem Sicherheitsvorfall im Juni 2025 im Mainnet deaktiviert. Eine Schwachstelle in der Logik zur Proof-Verifizierung – konkret ein fehlendes Element beim Hashing des Fiat-Shamir-Transkripts – ermöglichte es, gefälschte Proofs zu erstellen, die die Verifizierung bestehen konnten. Obwohl kein aktiver Exploit beobachtet wurde, führte das potenzielle Ausmaß dazu, dass das Programm über ein Feature Gate deaktiviert und vertrauliche Transfers pausiert wurden, bis Korrekturen und Audits abgeschlossen waren. Die Probleme sind nun behoben, die Implementierung wurde gehärtet und die Reaktivierung im Mainnet ist geplant.

G2-Arithmetik für alt_bn128

SIMD-0302: alt_bn128-G2-Syscalls hinzufügen erweitert Solanas bestehende kryptografische Syscalls für BN254 (alt_bn128) um native Operationen mit G2-Kurvenpunkten, darunter Addition, Subtraktion und Skalarmultiplikation. G1 und G2 sind die beiden elliptischen Kurvengruppen, die in der paarungsbasierten Kryptografie verwendet werden. G2 ist dabei über einem größeren Erweiterungskörper definiert.

Damit wird eine zentrale Lücke im aktuellen Syscall-Set geschlossen, das sich hauptsächlich auf G1-Operationen konzentriert. Gleichzeitig ermöglicht die Änderung eine umfassendere Unterstützung für paarungsbasierte Kryptografie direkt on-chain, insbesondere für Anwendungsfälle wie die Verifizierung von BLS-Signaturen und fortschrittliche ZK-Proof-Systeme.

Ohne native G2-Unterstützung waren einige Projekte auf eigene Implementierungen wie solana-alt-bn128-bls angewiesen. Dabei handelt es sich um eine vollständige BLS-Signaturbibliothek, die Dean Little von Blueshift auf Basis bestehender Syscalls entwickelt hat. G2-Operationen auf Syscall-Ebene würden solche Umgehungslösungen überflüssig machen und die native Entwicklung produktionsreifer kryptografischer Protokolle auf Solana vereinfachen.

Little-Endian-Unterstützung für alt_bn128

SIMD-0284: Little-Endian-Kompatibilität für alt_bn128 hinzufügen erweitert Solanas bestehende kryptografische Syscalls für alt_bn128 um Little-Endian-Formate für Ein- und Ausgaben. Zuvor akzeptierten diese Syscalls ausschließlich Big-Endian-Kodierung. Das erschwerte Entwicklern die Nutzung von Tools und Bibliotheken, insbesondere aus dem Ethereum-Ökosystem, da die meisten ZK-Teams auf Solana ark-bn254 verwenden, das mit Little-Endian arbeitet. Die Änderung ist abwärtskompatibel und erweitert die Unterstützung bestehender Anwendungsfälle mit Operationen auf elliptischen Kurven über alt_bn128.

BLS12-381-Syscalls

Abschließend führt SIMD-0388: BLS12-381-Syscalls native Unterstützung für kryptografische Operationen auf der elliptischen Kurve BLS12-381 ein. Damit erhalten Solana-Programme eine moderne, paarungsfreundliche Kurve mit 128-Bit-Sicherheit. Bisher stützte sich Solana bei paarungsbasierter Kryptografie auf BN254 (alt_bn128), das diesen Sicherheitsstandard nicht erfüllt und die Kompatibilität mit anderen weitverbreiteten Ökosystemen wie Ethereum einschränkt.

Statt eine völlig neue Syscall-Schnittstelle einzuführen, erweitert dieses Upgrade die bestehenden Kurven-Syscalls um neue Kennungen für G1- und G2-Operationen mit BLS12-381. Entwickler können dadurch über eine vertraute Schnittstelle Gruppenarithmetik, Punktvalidierung, Dekomprimierung und Batch-Prüfungen von Paarungen ausführen. Gleichzeitig werden die kryptografischen Möglichkeiten deutlich erweitert.

Neben allgemeinen Verbesserungen für Zero-Knowledge-Proofs und die Verifizierung von BLS-Signaturen ist diese Arbeit auch eine zentrale Voraussetzung für den Alpenglow-Konsens. Insbesondere können Validatoren damit BLS Proofs of Possession on-chain verifizieren und so Rogue-Key-Angriffe verhindern. Damit kommen wir zum nächsten Abschnitt.

Vorbereitung auf Alpenglow

BLS12-381-Syscalls sind nur eine von mehreren Feature-Gate-Aktivierungen im Release-Zyklus von Agave 4.0, die das Fundament für das Alpenglow-Konsensupdate legen. Nachfolgend findest du weitere Aktivierungen, die zum Rollout beitragen. Dieser soll derzeit im dritten Quartal 2026 zusammen mit Agave 4.1 im Mainnet erfolgen.

Validierung verketteter Block-IDs

SIMD-0340: Verkettete Block-ID validieren definiert, wie Validatoren die Abstammung von Blöcken prüfen müssen, um sowohl unter TowerBFT als auch unter dem Alpenglow-Konsens eine konsistente, kanonische Chain sicherzustellen. Slot-Nummern allein identifizieren Blöcke nicht eindeutig. Das gilt besonders bei Äquivokation, wenn mehrere Blöcke für denselben Slot erzeugt werden. Clients können sich deshalb nicht auf die Slot-Reihenfolge verlassen, um die korrekte Eltern-Kind-Beziehung zu bestimmen.

Diese Änderung führt explizite Regeln für die Chain-Validierung ein. Sie stellen sicher, dass jeder Block korrekt auf seinen übergeordneten Block verweist, verhindern Abweichungen und helfen dem Netzwerk, sich auf einen einzigen Verlauf zu einigen. Unter TowerBFT wird dies durchgesetzt, indem FEC-Sets sowohl innerhalb eines Slots als auch slotübergreifend auf den Merkle-Root ihres übergeordneten Blocks verweisen müssen. Alpenglow verwendet eine Konstruktion mit doppeltem Merkle-Root über alle FEC-Sets eines Slots. Schlagen diese Prüfungen fehl, wird der Block beziehungsweise Slot als inaktiv markiert. Diese Regeln erhöhen die Sicherheit des Konsenses und stellen sicher, dass sich Validatoren nach dem Empfang fehlerhafter oder widersprüchlicher Blöcke wiederherstellen können.

Marker für schnelle Leader-Übergaben

SIMD-0337: Marker für schnelle Leader-Übergaben in Alpenglow definiert explizite Signalisierungsregeln. Damit können Validatoren erkennen, wann ein übergeordneter Slot vollständig abgeschlossen ist und sicher als Grundlage dienen kann – eine Voraussetzung für schnelle Leader-Wechsel. Die Änderung führt strengere Vorgaben für die Platzierung von DATA_COMPLETE_SHRED sowie einen neuen „Parent Ready“-Marker ein. So lässt sich die Vollständigkeit eines Blocks eindeutig direkt aus dem Shred-Stream erkennen.

Heute können Unklarheiten darüber, ob ein Slot vollständig übertragen wurde, den nächsten Leader verzögern. Dieser muss möglicherweise auf weitere Shreds warten oder riskieren, auf unvollständigen Daten aufzubauen. Durch die Standardisierung des Abschlusssignals kann der nächste Leader früher und zuverlässig mit der Blockproduktion beginnen – ohne zusätzliche Koordination oder Mutmaßungen.

Dies ist ein zentraler Baustein für Alpenglows schnelle Leader-Übergabe. Dabei verbessert ein möglichst kleiner Abstand zwischen den Leadern direkt den Netzwerkdurchsatz.

Aktualisierung des Kostenmodells für Vote-Transaktionen

SIMD-0458: Keine statischen Kosten für SimpleVote-Transaktionen mehr verwenden entfernt die festen CU-Kosten für Vote-Transaktionen. Damit verwenden sie künftig dasselbe standardmäßige Transaktionskostenmodell wie andere Transaktionen. 

Heute werden für einfache Vote-Transaktionen konstant 3.428 CUs berechnet. Dieser Wert basiert auf früheren Annahmen zu deterministischen Ausführungskosten. Im neuen Modell werden Vote-Transaktionen wie alle anderen Transaktionen dynamisch gemessen. Dadurch wird die Kostenabrechnung konsistenter und ein separates Vote-CU-Limit überflüssig.

Der tatsächliche CU-Verbrauch von Vote-Transaktionen zur Laufzeit bleibt gleich. Ihre Berücksichtigung beim Packen von Blöcken ändert sich jedoch. Votes umfassen künftig insbesondere zusätzliche geschätzte ~16.000 CUs, etwa für die Kosten zum Laden von Account-Daten. Dadurch reservieren Leader beim Erstellen von Blöcken vorab mehr CUs.

Diese Änderung folgt auf SIMD-0387 (Verwaltung von BLS-Public-Keys im Vote-Account). Dadurch entfiel die Annahme, dass das Vote Program ein statisches Ausführungsprofil besitzt.

Weitere wichtige Upgrades

Weitere Highlights des Release-Zyklus von Agave 4.0 sind die Unterstützung für SBPFv3-Programme, die Möglichkeit zum Erstellen vorfinanzierter Accounts und Direct I/O zum Entpacken von Snapshots.

Unterstützung für SBPFv3-Programme

Der Release-Zyklus von Agave 4.0 umfasst ein Feature Gate, das die Bereitstellung und Ausführung von SBPFv3-Programmen ermöglicht. Solana Berkeley Packet Filter (SBPF) ist Solanas Rust-basierter Fork von eBPF: das Low-Level-Bytecodeformat und die virtuelle Maschine, in die On-Chain-Programme vor der Ausführung kompiliert werden. Dieses Update kombiniert Arbeiten aus drei SIMDs: SIMD-0178, SIMD-0189 und SIMD-0377. 

SIMD-0178 führt statische Syscalls ein. Dadurch können Syscall-Referenzen bereits beim Linken aufgelöst werden, statt über ELF-Relokationen zur Laufzeit. Heute machen diese Relokationen den Program Loader komplexer. Ihre Entfernung vereinfacht die Ausführung und senkt das Sicherheitsrisiko.

SIMD-0189 schränkt anschließend das zulässige ELF-Layout für Programme ein. Die strengere Dateistruktur reduziert die Zahl der Sonderfälle, die Validatoren parsen müssen, und die Menge unerwarteter Daten, die sie verarbeiten müssen. Für Entwickler sollte dies transparent sein, da die Linker-Toolchain voraussichtlich automatisch konforme Binärdateien erzeugt.

Abschließend passt SIMD-0377 die virtuelle SBPF-Maschine besser an den modernen, von LLVM erzeugten eBPF-Befehlssatz an. Dazu gehört die Unterstützung zusätzlicher Befehle wie 32-Bit-Sprungoperationen. Ziel ist es, Solanas VM kompatibler mit Upstream-Tools zu machen und Programme zugleich in effizienteren Bytecode kompilieren zu können. Für Entwickler bedeutet das in der Praxis: Programme laden schneller, die Angriffsfläche wird kleiner und der Rechenaufwand kann sinken, ohne dass sich die Anwendungslogik ändert.

Erstellen vorfinanzierter Accounts

SIMD-0312: CreateAccountAllowPrefund soll während des Release-Zyklus von Agave 4.0 im Mainnet aktiviert werden. Die Änderung führt eine neue Anweisung im System Program ein, durch die neu erstellte Accounts nicht mehr mit einem Lamport-Saldo von null beginnen müssen. Accounts können dadurch vor ihrer Erstellung vorfinanziert werden. Das vereinfacht einen häufigen Entwickler-Workflow und reduziert unnötige Anweisungen.

Bisher schlug die Anweisung CreateAccount fehl, wenn der Ziel-Account bereits Lamports enthielt. Entwickler mussten die Account-Initialisierung deshalb in mehrere Schritte aufteilen: normalerweise einen Transfer, gefolgt von Allocate und Assign. Das erhöht die Komplexität und verursacht zusätzliche Rechenkosten. Dieses Muster ist besonders häufig in Programmen anzutreffen, die Accounts im Voraus finanzieren.

Die neue Anweisung fasst diese Schritte in einem einzigen Aufruf zusammen, da sich vorfinanzierte Accounts direkt initialisieren lassen. In der Praxis reduziert dies den CPI-Overhead und kann in gängigen Abläufen Tausende Compute Units einsparen. Entwickler erhalten dadurch künftig einen saubereren und performanteren Pfad. Da dies als neue Anweisung eingeführt wird und bestehende Anweisungen unverändert bleiben, ist die Änderung vollständig abwärtskompatibel.

Direct I/O zum Entpacken von Snapshots 

Agave 4.0 verwendet beim Entpacken von Snapshots standardmäßig Direct I/O, statt Snapshot-Schreibvorgänge über den Page Cache des Betriebssystems zu leiten. Das verbessert die Startzeit und die Performance bei der Wiederherstellung von Snapshots. Dies ist besonders nützlich, weil Snapshot-Daten normalerweise auf die Festplatte gestreamt werden und keine häufiger verwendeten Validator-Daten aus dem Arbeitsspeicher verdrängen müssen. Betreiber können Direct I/O mit --no-accounts-db-snapshots-direct-io deaktivieren, wenn ihr Dateisystem O_DIRECT nicht unterstützt. In einem zukünftigen Release soll Direct I/O auch auf das Erstellen von Snapshots ausgeweitet werden. 

Fazit

Agave v4.0 ist ein umfangreiches Client-Upgrade mit zahlreichen Performance-Verbesserungen und Laufzeitoptimierungen. Die Änderungen machen das Netzwerk schneller, sicherer und einfacher zu entwickeln.

Der nächste Meilenstein ist Agave 4.1 mit dem Apenglow-Konsensupdate.

Weitere Ressourcen

• Release-Zeitplan für Agave 4.0
• Zeitplan des Feature Gate Tracker
• Änderungsprotokoll für Agave 4.0
• Pull Requests für Agave 4.0