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

Wichtige Updates im Release-Zyklus von Agave 2.1 

• Umfangreiche Leistungsoptimierungen
• Höhere Block-Limits
• Einführung des Greedy Schedulers (experimentell)
• Native Unterstützung für die Verifizierung von Secp256r1-Signaturen (Update: auf Agave 2.2 verschoben)
• Deaktivierung der Erhebung von Rent-Gebühren und der Rent-Rewrites
• Gelockerte Einschränkungen bei Fehlern während des Ladens von Transaktionen
• Migration der Config- und Address-Lookup-Table-Programme zu Core BPF

Jeder Abschnitt dieses Artikels ist eigenständig. So kannst du frei navigieren und dich auf die Themen konzentrieren, die dich am meisten interessieren. Ob du einen Validator betreibst, entwickelst oder Solana aktiv nutzt: Diese ausführliche Übersicht zu Agave 2.1 liefert dir die nötigen Einblicke, um diese Fortschritte effektiv zu nutzen.

Einführung der Funktionen

Zum Zeitpunkt der Veröffentlichung dieses Artikels laufen 88 % des Stakes mit Agave Version 2.1.11. Die Aktivierung von Feature Gates im Mainnet wurde vorübergehend pausiert, um eine breitere Einführung von v2.1 zu ermöglichen. Sie wird laut der geplanten Aktivierungsreihenfolge voraussichtlich in Kürze fortgesetzt. 

Die meisten neuen vollständigen Funktionen, die in den folgenden Abschnitten behandelt werden, sind derzeit noch nicht live. Sie sollen im Laufe des 2.1-Release-Zyklus über das Feature-Gate-System eingeführt werden. Funktionen werden abhängig von ihrer relativen Priorität und der Reihenfolge ihrer Aktivierung in Testnet- und Devnet-Clustern in bestimmten Epochen aktiviert.

Leistungsverbesserungen

Validator- und RPC-Betreiber berichten mit Agave 2.1 von spürbaren Verbesserungen bei Stabilität und Leistung. Im vergangenen Jahr hat Anza vorrangig Engpässe beseitigt, die Ressourceneffizienz optimiert und die Gesamtleistung verbessert. Bei neuen Client-Versionen geht es ebenso darum, die Grundlagen zu optimieren – Bandbreite erhöhen, Latenz reduzieren – wie neue Funktionen einzuführen. Bevor wir uns mit den Details des 2.1-Updates befassen, lohnt sich ein Blick auf die erheblichen Leistungsverbesserungen, die mit den jüngsten Client-Updates erzielt wurden.

Blockzeiten

Kürzere Blockzeiten auf Solana drücken die durchschnittlichen Slot-Zeiten unter 400 ms. Die jüngsten Epochen werden voraussichtlich in knapp zwei Tagen abgeschlossen – so schnell wie nie zuvor in der Geschichte des Netzwerks. Beide Clients sind für kürzere Blockzeiten bereit. Diese Beschleunigung bewirkt mehr als nur einen höheren Transaktionsdurchsatz. Da Staking-Belohnungen an Inflationsausschüttungen gekoppelt sind und diese anhand von „Epochenjahren“ statt Kalenderjahren berechnet werden, profitieren Validatoren und Staker. Ein Epochenjahr geht auf Basis der üblichen Epochenlänge von zwei Tagen von 182,5 Epochen pro Jahr aus. Wenn Epochen kürzer werden, passen mehr davon in denselben Zeitraum. Dadurch steigt effektiv die Rate, mit der Staking-Belohnungen ausgeschüttet werden.

Verfügbarkeit

Solana bewies 2024 und Anfang 2025 eine nahezu perfekte Zuverlässigkeit und erreichte über ein Jahr lang eine Verfügbarkeit von 100 %. Der letzte registrierte Ausfall ereignete sich am 6. Februar 2024, als ein bekannter Fehler die Finalisierung von Blöcken im Mainnet vorübergehend unterbrach. Das Problem wurde schnell identifiziert und behoben. Seitdem hat Solana ohne Unterbrechung Blöcke produziert, selbst bei intensiver Netzwerkaktivität – wie beim jüngsten Anstieg durch die Token-Launches der Trump-Familie. Das belegt die Widerstandsfähigkeit unter hoher Last.

Raten übersprungener Slots

Die Rate übersprungener Slots misst, wie oft ein Validator, der für einen bestimmten Slot als Leader ausgewählt wurde, innerhalb der vorgesehenen Zeit keinen Block produziert. Seit etwa Epoche 700 im November 2024 sind die Raten übersprungener Slots drastisch gesunken. Nachdem sie mehrere Jahre zwischen 2 % und 5 % schwankten, liegen sie bei den meisten gut optimierten Validatoren inzwischen nahe null.  

Zu dieser Verbesserung trägt die Einführung partitionierter Epochenbelohnungen im Mainnet in Epoche 707 bei. Indem Staking-Belohnungen auf mehrere Blöcke verteilt werden, reduziert diese Änderung Leistungsengpässe. Diese entstanden zuvor, weil die Ausschüttung der Belohnungen im ersten Block jeder neuen Epoche konzentriert war. Das Netzwerk arbeitet dadurch gleichmäßiger.

Zusätzlich schaffen die im November 2024 eingeführten Timely Vote Credits (TVC) Anreize für Validatoren, zeitnah abzustimmen, und wirken verzögerten Abstimmungen entgegen. Indem TVC die Zahl der Validatoren reduziert, die ihre Stimmen absichtlich zurückhalten, verbessert es die Konvergenz des Clusters und beschleunigt Bestätigung und Finalität. Dieser Mechanismus minimiert Forks und verkürzt ihre Dauer. Da die TVC-Bewertung inzwischen die Rangfolge von Stake Pools beeinflusst, haben Betreiber ihre Hardware aufgerüstet und ihre Validator-Konfigurationen für eine bessere Leistung optimiert.

Transaktionen pro Sekunde (TPS)

Mehr Transaktionen pro Sekunde (TPS) bedeuten einen höheren Durchsatz der Chain. Solanas Non-Vote-TPS (auch „True TPS“ genannt) steigen seit Ende 2023 kontinuierlich. Die neuesten Daten für die erste Februarwoche 2025 zeigen im Netzwerk beim 50. Perzentil durchschnittlich 1.228 TPS. Die Spitzenleistung im 99. Perzentil erreichte 2.520 TPS.  

Der bisherige TPS-Höchstwert wurde in der Woche des PENGU-Token-Airdrops bis zum 23. Dezember 2024 gemessen. Das 50. Perzentil lag im Durchschnitt bei 1.260 TPS, während das 99. Perzentil einen Spitzenwert von 3.252 TPS erreichte. Dieses anhaltende Wachstum unterstreicht Solanas kontinuierliche Skalierbarkeit und die effizientere Verarbeitung von Transaktionen.

Prioritätsgebühren

Ein Vergleich der erhobenen Prioritätsgebühren zwischen Agave 2.1 und der vorherigen Version 2.0 vom 27. Januar bis 4. Februar 2025 zeigt schließlich, dass Agave 2.1 durchgehend etwas höhere Prioritätsgebühren erhebt.

Block-Limits erhöhen

Eine Erhöhung der Block-Limits, vorgeschlagen in SIMD-0207: Block-Limit auf 50 Mio. erhöhen, ist für Solanas 2.1-Release-Zyklus geplant. Derzeit begrenzt das Protokoll die gesamten Rechenressourcen pro Block auf 48 Millionen Compute Units (CUs). Block-Limits stellen sicher, dass Nodes mit dem Netzwerk Schritt halten können. Dazu begrenzen sie den Arbeitsumfang, den ein Leader in einen Block packen kann. Das Gründungsteam wählte das aktuelle Limit empirisch anhand der Menge, die Validatoren realistisch verarbeiten können, um Blockzeiten von 400 Millisekunden zu erreichen. 

Die heutige Mainnet-Aktivität wird jedoch nicht durch Ausführungszeiten begrenzt. Blöcke könnten also mehr Transaktionen aufnehmen, ohne das Ziel von 400 ms zu überschreiten. Dieses Update erhöht das Limit moderat um 4 %, um die Netzwerkkapazität schrittweise auszubauen. Das Compute-Limit pro Block steigt von 48 Mio. auf 50 Mio. CUs. Eine stärkere Erhöhung, etwa eine Verdopplung des Limits, wäre zwar möglich, wurde für eine erste Änderung aber als zu riskant eingestuft. Höhere Block-Limits betreffen nicht nur Validatoren, sondern auch kritische Infrastruktur wie RPC-Nodes, Indexer und Archivierungsdienste, die entsprechend skalieren müssen.

Andere Protokolllimits bleiben unverändert:

• Das Compute-Limit pro Account und Block bleibt bei 12 Mio. CUs.
• Das maximale Compute-Limit pro Transaktion bleibt bei 1,4 Mio. CUs.

Weitere Erhöhungen der Block-Limits werden erwartet und sollen den formalen SIMD-Prozess durchlaufen.

Greedy Scheduler

Hintergrund: Der Central Scheduler

Das letzte große Scheduler-Update – der Central Scheduler – wurde im Mai vergangenen Jahres mit Agave 1.18 eingeführt. Dieser Scheduler erstellt einen Abhängigkeitsgraphen der N Transaktionen mit der höchsten Priorität, wobei N derzeit auf 256 festgelegt ist. Anschließend versucht er, Transaktionen in ihrer Prioritätsreihenfolge einzuplanen. Dabei stellt er sicher, dass Transaktionen ohne Konflikte zuerst verarbeitet werden. Nach der Planung werden diese Transaktionen aus dem Graphen entfernt. So können zuvor in Konflikt stehende Transaktionen priorisiert werden. Anschließend füllt der Scheduler den Graphen wieder auf, um eine Warteschlange von N Transaktionen aufrechtzuerhalten.

Dieser Ansatz wurde primär entwickelt, um größere Batches effizienter zu verarbeiten und den gesamten Transaktionsdurchsatz zu steigern. Ein großer Nachteil besteht jedoch darin, dass die Erstellung des Abhängigkeitsgraphen und die Sortierung der Transaktionen viel Zeit beanspruchen und so einen Engpass verursachen. 

Eine ausführlichere Übersicht zu Agave 1.18 und zur Implementierung des Central Schedulers findest du in unserem früheren Helius-Blogbeitrag.

Der neue Greedy Scheduler

Anders als der Central Scheduler erstellt der Greedy Scheduler keinen Abhängigkeitsgraphen. Stattdessen verfolgt er einen einfacheren Ansatz:

• Wähle zuerst die Transaktion mit der höchsten Priorität aus.
• Wenn die Transaktion nicht mit einem laufenden Batch in Konflikt steht, wird sie einer von vier Worker-Thread-Warteschlangen hinzugefügt.
• Treten Konflikte auf, wird der aktuelle Batch abgeschlossen und versendet. Die Transaktion wird einem neuen Batch hinzugefügt.

Diese Methode beschleunigt die Planung von Transaktionen deutlich, führt aber zu kleineren Batches und erhöht dadurch den Overhead pro Transaktion. Unter realen Mainnet-Bedingungen lohnt sich dieser Kompromiss jedoch, da die Ausführungszeit stärker von der BPF-Verarbeitung als vom Batching bestimmt wird.

Der Central Scheduler hat bei hoher Netzwerklast Schwierigkeiten, vor allem weil er Zeit benötigt, um Transaktionen zu sortieren und den Abhängigkeitsgraphen zu erstellen. Der Greedy Scheduler beseitigt diesen Overhead und reagiert dadurch schneller, ist beim Batching aber weniger effizient.

Betrachten wir ein Szenario, in dem Transaktionen in drei Konfliktgruppen fallen: A, B und C. Transaktionen stehen in Konflikt, wenn eine Transaktion in einen Account schreiben möchte, den eine andere Transaktion lesen oder ebenfalls beschreiben möchte. Transaktionen in A haben höhere Prioritätsgebühren als die in B oder C.

• Der Central Scheduler würde die konfliktfreien Transaktionen A1, B1 und C1 gemeinsam in einem Batch einplanen: [A1, B1, C1].
• Der Greedy Scheduler priorisiert zuerst die Transaktionen mit den höchsten Gebühren. Er plant A1 als separaten Batch ein und wechselt anschließend im nächsten Batch zu A2.

Diese Priorisierung ermöglicht eine schnellere Planung, kann jedoch zu kleineren Batches als beim Central Scheduler führen.

Natives Programm zur Verifizierung von Secp256r1-Signaturen

Solana führt ein neues natives Programm zur Verifizierung von Signaturen auf der elliptischen Kurve secp256r1 ein. Es ermöglicht Onchain-Unterstützung für Passkeys, den WebAuthn-Standard und neue Modelle für Account-Abstraktion, einschließlich Zwei-Faktor-Authentifizierung (2FA). Diese Verbesserung ebnet den Weg dafür, die in Web2 bereits weit verbreitete passwortlose Authentifizierung als zweiten Faktor für die Onchain-Sicherheit zu nutzen.

Die elliptische Kurve secp256r1 ist eine vom NIST standardisierte kryptografische Kurve und wird auf modernen Geräten umfassend unterstützt, darunter:

• WebAuthn: Ein W3C-Standard für die Authentifizierung mit Public-Key-Kryptografie, der von allen großen Webbrowsern unterstützt wird.
• Apples Secure Enclave: Eine hardwarebasierte Trusted Execution Environment (TEE), die Nachrichten signiert und nur über biometrische Authentifizierung zugänglich ist.
• Android Keystore: Eine API zur Verwaltung privater Schlüssel und Signaturmethoden, die die TEE des Geräts zur sicheren Speicherung von Schlüsseln nutzt.
• Passkeys: Ein Standard der FIDO Alliance und des W3C, der Passwörter durch kryptografische Schlüsselpaare ersetzt und mit Kryptografie auf elliptischen Kurven kompatibel ist.

Mehrere andere Netzwerke, darunter Ethereum (EIP-7212), haben ebenfalls die Integration von Unterstützung für die secp256r1-Kurve untersucht.

Details zum Secp256r1-Programm

Das neue Programm wird unter folgender ID bereitgestellt: Secp256r1SigVerify1111111111111111111111111

Struktur der Anweisung:

• Ein u8-Zähler gibt die Anzahl der zu verifizierenden Signaturen an.
• Darauf folgt ein einzelnes Padding-Byte.
• Für jede Signatur wird die folgende serialisierte Struktur verwendet:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

Dieses Update geht auf SIMD-0048: Natives Programm für Secp256r1 Sigverify zurück, das vom Bunkr-Team vorgeschlagen wurde. Das Secp256r1 SigVerify Precompile Program funktioniert ähnlich wie Solanas bestehende Unterstützung für secp256k1 und ed25519-Signaturen.

Erhebung von Rent-Gebühren deaktivieren und Rent-Rewrites überspringen

Zwei zusammenhängende Updates, vorgeschlagen in SIMD-0084: Erhebung von Rent-Gebühren deaktivieren und SIMD-0183: Rent-Rewrites überspringen, beseitigen einen Großteil des Legacy-Overheads, der mit Rent zahlenden Accounts verbunden ist.

Die Erhebung von Rent-Gebühren ist eine komplexe Komponente innerhalb der Bank. Ihre Deaktivierung vereinfacht die Codebasis des Validator-Clients und die Entwicklung aller Validator-Client-Implementierungen, da diese die Logik zur Rent-Erhebung nicht mehr nachbilden müssen. Rent wird nicht mehr von Accounts abgezogen und erhobene Rent-Gebühren werden nicht mehr an Validatoren ausgeschüttet. Neue Rent zahlende Accounts können bereits nicht mehr erstellt werden – jeder Versuch führt zu einem Transaktionsfehler.

Derzeit prüft die Rent-Erhebung jeden Account mindestens einmal pro Epoche. Dabei werden Accounts geladen und gespeichert, selbst wenn sie unverändert bleiben. Da alle Solana-Accounts bereits von Rent befreit sind, verursacht dieser Prozess nur unnötigen Rechenaufwand.

Rent-bezogene Rewrites von Accounts entfallen. Dadurch werden pro Slot weniger Accounts gespeichert. Validatoren profitieren von einer höheren Leistung, da weniger Accounts in die Berechnung des Accounts Delta Hash und des inkrementellen Account Hash einfließen. Diese Änderung reduziert außerdem die Größe inkrementeller Snapshots und senkt den Ressourcenverbrauch weiter.

Transaktionseinschränkungen lockern: Ladefehler

Derzeit gelten für Solana-Transaktionen strenge Einschränkungen, durch die sie fehlschlagen können, bevor sie in einen Block aufgenommen werden. Diese Fehler vor der Blockaufnahme verschwenden Rechenleistung der Validatoren: Ressourcen werden verbraucht, ohne dass Transaktionsgebühren anfallen – die Arbeit bleibt also unbezahlt.

Die Blockproduktion wird zusätzlich dadurch erschwert, dass Transaktionen herausgefiltert werden müssen, die ungültige Programme aufrufen oder das maximale Limit von 64 MiB (~67,11 MB) für geladene Account-Daten überschreiten. Diese Einschränkungen machen das Zusammenstellen von Blöcken komplexer und erschweren die Prüfung ihrer Gültigkeit. Durch eine Lockerung dieser Einschränkungen könnten Transaktionen in einen Block aufgenommen und mit Gebühren belastet werden, ohne Programmdaten vorher zu laden und zu verifizieren. Diese Änderung soll die Abhängigkeit der Blockvalidierung vom Zustand der Accounts beseitigen.

Diese in SIMD-0191 vorgeschlagenen Änderungen können sich auf Tools wie Blockchain-Explorer auswirken, die davon ausgehen, dass alle Transaktionen eine Ausführung versuchen. Außerdem müssen Nutzer sicherstellen, dass ihre Transaktionen ausführbar sind, um unnötige Gebühren zu vermeiden.

Migration der Config- und Address-Lookup-Table-Programme zu Core BPF

Im Rahmen der laufenden Umstellung von nativ verankerten Programmen auf Berkeley-Packet-Filter-Programme (BPF) werden das Config-Programm und die Address Lookup Table Programs zu Core BPF Programs migriert. Diese Umstellung entkoppelt diese kritischen Programme von der Validator-Runtime. Das ermöglicht flexiblere Updates und vereinfacht die Wartung.

BPF-Programme sind weniger komplex als ihre nativen Gegenstücke. Das vereinfacht Entwicklung und Wartung über verschiedene Validator-Clients hinweg. Durch diese Änderung müssen die Teams von Firedancer und Anza Programmänderungen nicht mehr separat in ihren Runtimes nachverfolgen und implementieren. Stattdessen werden Updates einheitlich auf alle Clients angewendet. 

Die neu implementierten Programme behalten dieselben ABIs wie ihre nativen Versionen bei. Das gewährleistet vollständige Kompatibilität. Sie unterscheiden sich lediglich bei der Compute-Nutzung.

Fazit

Das Update auf Agave 2.1 ist ein großer Fortschritt für Solana und führt wichtige Funktionsverbesserungen sowie Optimierungen der Runtime ein. Diese Version stärkt das Netzwerk, indem sie den Funktionsumfang erweitert, die Leistung optimiert und die Grenzen dessen verschiebt, was Solana leisten kann. Mit nativer Unterstützung für die Verifizierung von Secp256r1-Signaturen, höheren Block-Limits, umfangreichen Leistungsverbesserungen und der späteren Einführung des Greedy Schedulers steigert Agave 2.1 sowohl Effizienz als auch Skalierbarkeit. Ob du entwickelst, einen Validator betreibst oder Solana aktiv nutzt: Dieses Update eröffnet neue Möglichkeiten und macht Solana schneller, flexibler und leistungsfähiger als je zuvor.

Weitere Ressourcen

• Repository des Agave-Clients
• Release-Zeitplan für Agave v2.1
• Mit Agave v2.1 markierte Pull Requests