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

Wichtige Updates im Release-Zyklus von Agave 2.2 

• Umfangreiche Performance-Optimierungen
• Erhöhung der Block-Limits um 20 % von 50 Mio. auf 60 Mio. CUs
• Einführung des Accounts Lattice Hash (ALH)
• Secp256r1-Signaturverifizierung (aus dem Release-Zyklus von Agave 2.1 verschoben)
• Deployment und Ausführung von SBPFv1-, v2- und v3-Programmen
• Aufhebung der Einschränkung für CPI-Aufrufer
• Loader-v4

Jeder Abschnitt dieses Artikels ist eigenständig. So kannst du gezielt die Themen erkunden, die für dich am relevantesten sind. Ob du Validatoren betreibst, entwickelst oder das Netzwerk aktiv nutzt: Dieser umfassende Leitfaden zu Agave 2.2 liefert dir die wichtigsten Informationen, damit du die neuesten Verbesserungen voll ausschöpfen kannst.

Einführung der Funktionen

Zum Zeitpunkt der Veröffentlichung laufen 19,8 % des gesamten Stakes auf Agave v2.2.* Das signalisiert starke Unterstützung für eine netzwerkweite Einführung. Die Aktivierungen von Feature Gates im Mainnet wurden während des Upgrade-Zeitraums vorübergehend pausiert. Sie sollen kurz nach der geplanten Aktivierungssequenz fortgesetzt werden.

Die meisten wichtigen Funktionen aus Agave 2.2 sind derzeit durch Feature Gates geschützt und im Mainnet noch nicht aktiv. Sie werden während des Release-Zyklus von 2.2 schrittweise über das Feature-Gate-System von Solana aktiviert. Der Aktivierungszeitpunkt richtet sich nach der Priorität der Funktionen und der Reihenfolge ihrer Einführung in Testnet- und Devnet-Clustern. Aktuelle Informationen findest du im Tracker für Agave Feature Gates.

Block-Limits auf 60 Mio. CUs erhöhen

Anza hat sich für 2025 ein ehrgeiziges Ziel gesetzt: den verfügbaren Blockspace auf Solana zu verdoppeln. Im Rahmen dieser Initiative soll SIMD-0256: Block-Limits auf 60 Mio. erhöhen in das kommende Solana-2.2-Release aufgenommen werden. Das entspricht einer Erhöhung um 20 % gegenüber dem aktuellen Block-Limit.

Dies folgt auf ein früheres Upgrade, das die Block-Limits von 48 Millionen auf 50 Millionen Compute Units (CUs) erhöhte. Danach blieben die Blockzeiten durchgehend unter dem Zielwert von 400 ms. Aktuelle Daten zeigen, dass Blöcke das Limit von 50 Mio. CUs regelmäßig ausschöpfen. Das signalisiert, dass das Netzwerk für eine weitere Skalierung bereit ist.

Hinweis: Einige Blöcke erscheinen zu 104 % ausgelastet. Der Grund dafür ist eine fest codierte Konstante in der Berichtslogik des Firedancer-Dashboards.

Andere Protokolllimits bleiben mit diesem Update unverändert:

• Das Compute-Budget pro Konto und Block bleibt unverändert bei 12 Millionen CUs.
• Das maximale Compute-Budget pro Transaktion bleibt auf 1,4 Millionen CUs begrenzt.
• Das gesamte Compute-Limit für Vote-Transaktionen pro Block bleibt bei 36 Millionen CUs.
• Die maximale Zuweisung neuer Kontodaten pro Block bleibt auf 100 MB begrenzt.

Höhere Block-Limits wirken sich direkt auf die User Experience aus: Ein höherer Netzwerkdurchsatz senkt die medianen Transaktionsgebühren und erhöht die Wahrscheinlichkeit, dass Transaktionen bei hoher Auslastung erfolgreich aufgenommen werden.

Herausforderungen bei der Erhöhung der Block-Limits

Um den Durchsatz zu steigern, sollten die Block-Limits vorsichtig und schrittweise erhöht werden. Dabei müssen zwei zentrale Herausforderungen gelöst werden:

1. Bereitschaft der Infrastruktur

Die Infrastruktur des gesamten Ökosystems muss mit den Optimierungen des Core-Clients Schritt halten. Insbesondere darf die Schreibschicht die Leseschicht, etwa RPC-Nodes, Indexer und Archivdienste, nicht überholen. Andernfalls leidet die User Experience.

2. Rechtzeitige Block-Übertragung

Ein weiterer Engpass ist die Übertragung von Blöcken vom Leader-Node an den restlichen Cluster. Deutlich größere Blöcke könnten dazu führen, dass die Verteilung länger als die angestrebten 400 ms dauert, besonders bei hoher Last.

Eine drängende Herausforderung ist die Retransmit-Phase der Transaction Validation Unit (TVU), über die Shreds im Cluster verteilt werden. Große Validatoren erreichen fast 150.000 ausgehende Pakete pro Sekunde (PPS), da Turbine einen hohen Fanout-Faktor von 200 verwendet. Das bedeutet, dass jeder Node Shreds an 200 weitere Nodes weiterleiten muss. Eine ineffiziente Verarbeitung kann zu Shred-Rückständen, unregelmäßigen Leader-Wechseln und inkonsistenten Ansichten des Netzwerkzustands führen.

Um dieses Problem zu lösen, überarbeiten die Engineers von Anza derzeit die Pipeline zur Blockverteilung. Das Team arbeitet am Umstieg auf XDP (eXpress Data Path). Dabei lässt sich der Kernel umgehen, da die Paketverarbeitung direkt im User Space verfügbar wird. Dieser Ansatz vermeidet kostspielige Zwischenkopien und ermöglicht der Validator-Software, direkt mit der Netzwerkkarte (NIC) zu kommunizieren.

Accounts Lattice Hash (ALH)

Damit Solana Milliarden von Konten unterstützen kann, muss das Hashing des globalen Kontostands besser skalieren. Der neu eingeführte Accounts Lattice Hash (ALH) ersetzt die bisherigen Merkle-basierten Konto-Hashes durch eine effizientere und skalierbarere Alternative auf Basis homomorphen Hashings. Damit lässt sich aus vorhandenen Hashes ein neuer Hash erstellen, ohne alles von Grund auf neu berechnen zu müssen.

Solana verwaltet derzeit zwei Hashes für den Kontostand:

• Epoch Accounts Hash (EAH): Eine Merkle-Root des gesamten Kontostands, die einmal pro Epoche berechnet wird.
• Accounts Delta Hash (ADH): Eine Merkle-Root der innerhalb eines einzelnen Blocks geänderten Konten, die für jeden Block neu berechnet wird.

Beide Ansätze sortieren Konten nach ihrem öffentlichen Schlüssel und erstellen Merkle-Bäume. Das führt zu Performance- und Skalierungsproblemen, besonders wenn die Zahl der Konten wächst. Das Modell mit zwei Hashes entstand als Kompromiss: EAH war genau und umfasste den gesamten Kontostand, wurde aber nur selten berechnet. ADH wurde häufig berechnet, deckte aber nur geänderte Konten ab. Idealerweise würde jeder Block einen vollständigen und aktuellen Hash des gesamten Kontostands enthalten, ohne den Aufwand, einen Merkle-Baum neu zu berechnen.

So funktioniert der Accounts Lattice Hash

Der ALH erreicht dieses Ziel mit einer homomorphen Hashfunktion, die inkrementelle Updates ermöglicht. Statt jedes Mal einen Merkle-Baum neu aufzubauen, addiert oder subtrahiert der ALH einzelne Konto-Hashes (LtHashes), wenn Konten beschrieben werden. Das Ergebnis ist ein einzelner Hash mit 2048 Byte, der den Zustand aller Konten zusammenfasst. Entscheidend ist, dass er Block für Block aktualisiert werden kann, ohne ihn von Grund auf neu zu berechnen.

Dieser Ansatz hat eine Komplexität von O(n). Das ist eine deutliche Verbesserung gegenüber der Komplexität O(n log n) von Merkle-Bäumen. So kann jeder Block einen Hash des gesamten Kontostands enthalten, ohne kostspielige Neuberechnung.

Integration und außer Betrieb genommene Hashes

Die Einführung umfasst drei separate SIMDs mit jeweils unabhängigen Aktivierungen der Feature Gates im Release-Zyklus von Agave 2.2.

• SIMD-0215: Accounts Lattice Hash
• SIMD-0220: Snapshots verwenden Accounts Lattice Hash
• SIMD-0223: Entfernt Accounts Delta Hash

Mit diesen Änderungen ersetzt der Accounts Lattice Hash sowohl ADH als auch EAH. ALH wird in den Bank-Hash jedes Blocks integriert. Dadurch lässt sich der vollständige Zustand bei jedem Block statt nur bei jeder Epoche hashen.

Performance und Kompromisse

Der Wechsel zu ALH bietet erhebliche Performance-Vorteile für Validatoren, da das Merkle-basierte Hashing für jeden Block entfällt. Dadurch werden Konsens und Snapshot-Erstellung effizienter. Validatoren müssen Konten beispielsweise während der Blockfinalisierung oder Snapshot-Erstellung nicht mehr sortieren oder Bäume neu aufbauen. ALH-Updates sind einfache additive Operationen.

Anders als Merkle- oder Verkle-Bäume unterstützt dieser Ansatz jedoch keine Inklusions- oder Exklusionsnachweise. Das betrifft bestimmte Anwendungsfälle für kryptografische Verifizierung, etwa Light Clients und Simple Payment Verification (SPV). Angesichts der drastischen Effizienzsteigerungen gilt dieser Kompromiss jedoch als sinnvoll. Eine Diskussion über alternative Methoden für Inklusionsnachweise findest du hier.

Snapshot-Integration

Da die erstmalige Berechnung des Accounts Lattice Hash aufwendig ist, wird der ALH-Wert nun dauerhaft in Validator-Snapshots gespeichert und beim Start wiederhergestellt, sofern er verfügbar ist. Snapshots verwenden künftig das aktualisierte ALH-Format statt Merkle-basierter Snapshot-Hashes. Dadurch richten sich Solanas Speicher- und Hashing-Modell noch stärker an diesem neuen Design aus.

Native Secp256r1-Signaturverifizierung

Solana ergänzt native Unterstützung für die Signaturverifizierung mit der elliptischen Kurve secp256r1. Dieses wichtige Upgrade ermöglicht Onchain-Kompatibilität mit Passkeys, dem WebAuthn-Standard und fortgeschrittenen Modellen zur Kontoabstraktion, einschließlich Zwei-Faktor-Authentifizierung (2FA). Das Update bringt die in Web2 bereits allgegenwärtige passwortlose Authentifizierung in Web3 und verbessert so die Sicherheit und Benutzerfreundlichkeit von Onchain-Anwendungen.

Die Funktion war ursprünglich für das Release Agave 2.1 geplant, wurde jedoch auf 2.2 verschoben. Weitere Einzelheiten findest du in unserer umfassenden Analyse der Secp256r1-Signaturverifizierung im Agave-2.1-Update.

Fehler bei der Ausrichtung von Precompiles

Kurz nach der ersten Einführung von Agave 2.2 wurde ein kritischer Fehler in der Implementierung der Precompile-Programme Secp256r1 und Ed25519 entdeckt. Der Fehler trat unter dem neuen View-Flag `--transaction-structure` auf. Dieses legt rohe Transaktionslayouts offen, ohne deren Ausrichtung zu garantieren. Die Precompiles gingen für Anweisungsdaten fälschlicherweise von einer 2-Byte-Ausrichtung aus. Das führte zu unterschiedlichen Ausführungsergebnissen bei Blockproduzenten und Validatoren. Dadurch stimmten Bank-Hashes nicht überein und Leader mussten abbrechen, was die Verfügbarkeit beeinträchtigte. Das Problem wurde erstmals am 9. April gemeldet und bis zum 11. April umgehend behoben. Der Fehler hatte keine Auswirkungen auf Benutzergelder. Weitere Einzelheiten findest du in der kurz darauf veröffentlichten Ursachenanalyse.

Deployment und Ausführung von SBPFv1-, v2- und v3-Programmen

Der Solana Berkeley Packet Filter (SBPF) ist eine speziell entwickelte virtuelle Maschine, die Solana-Programme effizient und sicher ausführt. Er ist ein Rust-basierter Fork des ursprünglich für Linux entwickelten Extended Berkeley Packet Filter (eBPF). 

Upgrades für Solanas Berkeley Packet Filter (SBPF) sind entscheidend, um die Performance zu verbessern, die Sicherheit zu erhöhen und neue Möglichkeiten für Anwendungsentwickler zu erschließen. Agave 2.2 schafft die Grundlage für langfristige Wartbarkeit und Performance-Upgrades. Dazu führt es ein formales Versionierungssystem für die virtuelle SBPF-Maschine ein, das erstmals in SIMD-0161 beschrieben wurde. Diese Änderung ermöglicht das Deployment und die Ausführung von SBPFv1- (SIMD-0166), SBPFv2- (SIMD-0173, SIMD-0174) und SBPFv3-Programmen (SIMD-0178, SIMD-0179, SIMD-0189). Damit entsteht ein nachhaltiges Framework, um die Programmausführungsumgebung schrittweise weiterzuentwickeln, ohne netzwerkweite erneute Deployments zu erfordern.

Bisher mussten alle SBPF-Upgrades über globale Feature Gates eingeführt werden. Das machte die Weiterentwicklung der Runtime umständlich und die Koordination von Deployments nahezu unmöglich. Die Versionierung löst dieses Problem, indem sie das Programmverhalten von der globalen Runtime entkoppelt und stattdessen an ein programmspezifisches Versions-Tag bindet. Dieses ist im Feld e_flags des Headers einer Executable-and-Linkable-Format-Datei (ELF) codiert. Dieser Ansatz ermöglicht Folgendes:

Explizites Runtime-Verhalten

Jedes Programm gibt die erwartete Befehlssatzarchitektur an, also eine SBPF-Version. Die Runtime des Programms passt ihr Verhalten an diese Version an.

Kontrollierte Einführung

Feature Gates aktivieren das Deployment und die Ausführung neuer SBPF-Versionen unabhängig voneinander. Ältere Versionen werden mit der Zeit schrittweise eingestellt. Ganze Änderungspakete werden in eigenständigen SBPF-Versionen gebündelt. Dadurch lassen sich Upgrades sauberer und einfacher verwalten.

Schrittweise Einstellung

Die Unterstützung für ältere SBPF-Versionen kann nach deren Einstellung vollständig entfallen. Das vereinfacht die Logik der virtuellen Maschine. Dieser Prozess erfolgt langsam, damit Entwickler ausreichend Zeit haben, ihre Programme zu migrieren oder erneut bereitzustellen und an neuere Versionen anzupassen.

Versionsdiskriminator

Derzeit behandelt das Protokoll jeden e_flags-Wert außer 0x0020 als SBPF v0. Im bestehenden System ist das gültig. Dieser Ansatz skaliert jedoch nicht für mehrere SBPF-Versionen und muss aktualisiert werden.

Sobald das erste Feature Gate für eine neue SBPF-Version aktiviert wird, ändert das Protokoll die Interpretation von e_flags und ordnet den Wert direkt der entsprechenden SBPF-Versionsnummer zu. In diesem System steht 0x0000 für SBPF v0, 0x0001 für SBPF v1 und so weiter.

Einschränkung für CPI-Aufrufer aufheben

Der Release-Zyklus von Agave 2.2 umfasst eine lang erwartete Verbesserung, die eine historische Einschränkung für Cross-Program Invocations (CPI) beseitigt. Derzeit muss jedes über CPI aufgerufene Programm vom Aufrufer explizit als Anweisungskonto übergeben werden. Das macht die Transaktionskonstruktion komplex und verursacht erheblichen Compute-Aufwand, besonders bei tief verschachtelten CPIs. Diese Einschränkung ist jedoch rein historisch bedingt und für das aktuelle Protokoll nicht erforderlich.

SIMD-0163 hebt diese Einschränkung auf. CPI-Anweisungen können Programmkonten dann direkt aus der übergeordneten Kontoliste der Transaktion referenzieren. Die Konten müssen nicht mehr rekursiv durch jede Aufrufebene gereicht werden. Diese Änderung bietet folgende Vorteile:

• Reduziert die CU-Nutzung drastisch, da Programmkonten nicht mehr redundant serialisiert und deserialisiert werden. Ausgenommen sind loader-v3-Programme, die ihre ausführbare Datei in einem separaten Konto speichern. Aufgrund der Größe dieser Dateien (Binärdateien mit ~10 MB) ist dieser Vorgang besonders teuer.
• Vereinfacht die Transaktionskonstruktion, da die Programmkonten der aufgerufenen Programme nicht mehr durch Anweisungsstapel gereicht werden müssen.
• Verbessert die Komponierbarkeit und erleichtert den Aufbau modularer, tief verschachtelter Programmarchitekturen.

Abwärtskompatibilität

Bestehende Programme bleiben davon unberührt, sofern sie diese Änderung nicht nutzen möchten. Andernfalls haben sie folgende Möglichkeiten:

Programme, in denen das aufgerufene Programm statisch fest codiert ist und nur als beliebiges Anweisungskonto benötigt wird, um die Einschränkung der Runtime zu erfüllen, können einen Platzhalter wie NativeLoader1111111111111111111111111111111 erhalten. So verschieben sich die Indizes der anderen Anweisungskonten nicht.

Alle anderen bestehenden Programme, die dynamisch das aufrufen, was in einem bestimmten Anweisungskonto übergeben wird, müssen aktualisiert und erneut bereitgestellt werden, um von der aufgehobenen Einschränkung zu profitieren.

Diese Optimierung beeinträchtigt die Sicherheit nicht. Die Funktion „verzögerte Sichtbarkeit“ verhindert, dass Programme andere Programme aufrufen, die innerhalb derselben Transaktion hinzugefügt, geändert oder entfernt wurden.

Loader-v4

Agave 2.2 unterstützt erstmals Loader-v4. Dieser schlanke und flexiblere Mechanismus für Programm-Deployments soll Loader-v3 ersetzen. Loader-v4 wird über SIMD-0167 aktiviert. Er vereinfacht die Verwaltung von Programmkonten, verbessert Upgrade-Abläufe und führt wichtige Sicherheitsfunktionen für aktive Programme ein, besonders in Umgebungen mit hohen Risiken wie DeFi.

Zentrale Funktionen von Loader-v4:

Einzelkontomodell: Loader-v4 macht Proxy-Konten und separate Puffer für Programmdaten überflüssig. Jedes Programm wird jetzt durch ein einziges Konto dargestellt.

Wartungsmodus

Programme können jetzt in einen nicht ausführbaren „Wartungsmodus“ versetzt werden, ohne sie dauerhaft zu schließen oder erneut bereitzustellen. Die ursprüngliche Programmadresse bleibt erhalten. So können Entwickler die Ausführung pausieren, etwa bei einem Exploit, ohne die Adresse aufzugeben.

Beliebige Größenänderung

Mit Loader-v4 lassen sich Programmbinärdateien nach dem Deployment vergrößern und verkleinern. Das ermöglicht eine flexiblere Ressourcenzuweisung und gibt gebundene Mittel wieder frei.

Optionale Puffernutzung

Anders als Loader-v3, das für erneute Deployments immer ein externes Pufferkonto erforderte, macht Loader-v4 Puffer optional. Programme können nun direkt erneut im Hauptprogrammkonto bereitgestellt werden. Dadurch halbiert sich der Betrag, der während des Uploads gebunden werden muss.

Partielle erneute Deployments

Bei Loader-v3 mussten für jedes Upgrade die vollständigen Programmbinärdateien erneut hochgeladen werden. Loader-v4 unterstützt dagegen partielle Uploads. Entwickler können so nur bestimmte Bereiche eines Programms patchen. Das ist besonders bei kleineren Updates nützlich.

Nahtlose Migration von Loader-v3

Mit Loader-v3 bereitgestellte Programme können zu Loader-v4 migriert werden, ohne ihre Programmadresse zu ändern. Das ermöglicht eine neue Migrate-Anweisung in Loader-v3. Diese Aktion verzögert die Sichtbarkeit. Das Programm ist daher für den Rest des aktuellen Slots nicht verfügbar.

Nach der Aktivierung von Loader-v4 wird ein separates Feature Gate ausgelöst, das neue Deployments mit Loader-v3 deaktiviert. Bestehende Loader-v3-Programme bleiben funktionsfähig. Für alle zukünftigen Deployments soll jedoch Loader-v4 verwendet werden.

Beim Finalisieren eines loader-v4-Programms kann eine Adresse der nächsten Version angegeben werden, wodurch sich möglicherweise eine verkettete Liste bildet. Das bietet eine Alternative zu erneuten Programm-Deployments und ermöglicht Benutzeroberflächen, eine Liste finalisierter Programmversionen zur Auswahl anzubieten.

Die Mechanismen zur Verwaltung von Autoritäten und zum Schließen von Konten bleiben in Loader-v4 unverändert. All diese Funktionen werden über den neuen CLI-Unterbefehl program-v4 verfügbar sein.

Fazit

Agave 2.2 ist ein wichtiger Meilenstein für das Solana-Protokoll. Es bringt entscheidende Runtime-Verbesserungen und neue Funktionen, die die technischen Möglichkeiten des Netzwerks erweitern. Das Release führt mehrere zentrale Änderungen ein: 20 % mehr Blockkapazität, die Integration des Accounts Lattice Hash (ALH) für skalierbares State-Hashing, mehrere Verbesserungen für die Programmentwicklung und Unterstützung für die Secp256r1-Signaturverifizierung, die für gängige kryptografische Integrationen entscheidend ist. Zusammen erhöhen diese Verbesserungen den Durchsatz, optimieren die Developer Experience und ermöglichen dem Netzwerk, ein breiteres Anwendungsspektrum zu unterstützen.

Ob du Programme entwickelst, Validatoren betreibst oder mit dem Netzwerk interagierst: Agave 2.2 erschließt mehr Performance, Flexibilität und Robustheit für Solana.

Weitere Ressourcen

• Agave-Client-Repository
• Release-Zeitplan für Agave v2.2
• Änderungsprotokoll für Agave v2.2
• Mit Agave v2.2 markierte Pull Requests