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

Einführung

Mit Agave 4.4 baut Solanas zentraler Validator-Client auf dem Rollout von Alpenglow auf. Das Release vereinfacht die Blockvalidierung, optimiert die Berechnung von Staking-Belohnungen und senkt die SOL-Menge, die zum Speichern von Programmen und Account-Daten erforderlich ist. Diese Änderungen steigern die Effizienz im täglichen Betrieb und schaffen weitere Grundlagen für die asynchrone Ausführung. Da die Zielzeit für Slots kürzlich auf 200 ms reduziert wurde, dauern Epochen nur noch etwa einen Tag. Dadurch lassen sich Feature Gates noch schneller aktivieren.

Wichtige Neuerungen im Release-Zyklus von Agave 4.4

• Ungültige Gebührenzahler zulassen: Ein wichtiger Schritt hin zur asynchronen Ausführung
• Automatische Größenanpassung von Programmen: Erstattet überschüssige Rent bei Programm-Upgrades
• Standardisierung von Shreds: Das Protokoll erzwingt jetzt FEC-Sets mit 32 Daten- und 32 Coding-Shreds
• Bereinigung inaktiver Stakes: Schließt inaktive Stakes von der Berechnung der Belohnungen aus
• Rent-Reduzierung: Die letzten drei geplanten Stufen der 90-prozentigen Senkung der Zustandskautionen

Ungültige Gebührenzahler zulassen

Die Aktivierung des Feature Gates für SIMD-0290: Einschränkung für Gebührenzahler lockern wird voraussichtlich im Release-Zyklus von Agave 4.4 erfolgen. Dadurch ändert sich, was passiert, wenn ein Block eine Transaktion enthält, deren Gebührenzahler die Validierung nicht besteht, etwa wegen unzureichender SOL. Bisher machte eine solche Transaktion den gesamten Block ungültig. Nach den neuen Konsensregeln bleibt die Transaktion im Block. Validatoren überspringen jedoch ihre Ausführung, sodass sich der Account-Zustand nicht ändert.

Der Kontostand eines Gebührenzahlers kann sich durch die Ausführung vorheriger Transaktionen ändern. Wenn jede Transaktion einen gültigen Gebührenzahler benötigt, müssen Validatoren daher zunächst einige vorherige Transaktionen ausführen, bevor sie die Gültigkeit eines Blocks bestimmen können. Werden Transaktionen mit ungültigem Gebührenzahler übersprungen, entfällt diese Abhängigkeit.

Dies schafft die Grundlage für die asynchrone Ausführung. Dabei können sich Validatoren auf Blöcke und die Reihenfolge der Transaktionen einigen, bevor die Ausführung abgeschlossen ist. Die Ausführung erfolgt separat und wendet die vereinbarten Transaktionen auf den Account-Zustand an. Solana bewegt sich auf dieses Modell zu, um künftige Verbesserungen wie kürzere Blockzeiten und mehrere gleichzeitig aktive Block-Proposer zu ermöglichen.

Agave stellt diese übersprungenen Transaktionen als No-Ops dar: Sie führen keine Anweisungen aus und zahlen keine Gebühren. Entsprechend ihren vollständig angeforderten oder standardmäßigen Ressourcenbudgets belegen sie dennoch Blockkapazität. Das begrenzt, wie viele davon ein Leader aufnehmen kann. Die Implementierung erlaubt dem Leader weiterhin, sie bei der Blockproduktion herauszufiltern, obwohl Validatoren sie beim Replay eines Blocks akzeptieren können.

SIMD-0290 gilt speziell für Transaktionen, die einen aktuellen Blockhash als Gültigkeitsangabe verwenden. Transaktionen mit Durable Nonce erfordern eine zusätzliche Behandlung, die separat in SIMD-0297: Einschränkung für ungültige Nonce-Transaktionen lockern behandelt wird. Die Änderung ist vollständig abwärtskompatibel. Alle zuvor gültigen Transaktionen und Blöcke bleiben gültig.

Automatische Größenanpassung von Programmen bei Upgrades

Agave 4.4 wird ein Feature Gate für SIMD-0433: Loader V3: Programmdaten auf ELF-Länge setzen aktivieren. Dadurch passen Programm-Upgrades automatisch die Größe des Accounts an, in dem der kompilierte Code des Programms gespeichert ist.

Loader v3, also der aktuelle Standard-Loader zum Bereitstellen und Aktualisieren von Solana-Programmen, speichert die kompilierte ELF-Binärdatei eines Programms zusammen mit Metadaten wie seiner Upgrade-Autorität in einem ProgramData-Account. Bisher konnten Entwickler diesen Account nur vergrößern, aber nie verkleinern. Bei einem Upgrade auf eine kleinere Binärdatei blieb daher ungenutzter Speicherplatz zurück. Die SOL, die erforderlich waren, um diesen Speicherplatz von der Rent zu befreien, blieben im Account gebunden.

Mit dieser Änderung passt die Upgrade-Anweisung die Account-Größe an den Metadaten-Header plus die Länge der neuen ELF-Datei an. Eine kleinere Binärdatei überträgt überschüssige Lamports an den Spill-Account des Upgrades, also den festgelegten Empfänger für verbleibende Mittel. Bei einer größeren Binärdatei wird der Account automatisch erweitert. Damit entfällt bei gewöhnlichen Upgrades der separate Erweiterungsschritt. Der ProgramData-Account und die Buffer-Accounts müssen bereits genügend Lamports enthalten, um die neue Rent-Anforderung zu erfüllen. Andernfalls schlägt das Upgrade fehl.

Entwickler, die kleinere Binärdateien einsetzen, können somit beim nächsten Upgrade SOL zurückerhalten. Auch zuvor reservierte freie Kapazität wird entfernt. Für über CPI aufgerufene Upgrades gilt weiterhin das Limit von 10 KiB für das Account-Wachstum: Größere Erweiterungen erfordern eine vorherige Vergrößerung oder eine Upgrade-Anweisung auf oberster Ebene. Entwickler sollten vor dem Upgrade das Ziel ihres Spill-Accounts prüfen, damit Rückerstattungen beim vorgesehenen Empfänger ankommen.

Diese Änderung schafft Anreize für Entwickler, auf neuere und leistungsfähigere Bibliotheken und Frameworks wie Pinocchio umzusteigen. Außerdem reduziert sie den Speicherplatz, den Programme in der Accounts DB belegen.

Standardisierung von Shreds

Agave 4.4 verschärft die in SIMD-0317: 32 Daten- + 32 Coding-Shreds erzwingen beschriebenen Regeln für die Blockverteilung von Solana. Dadurch wird die Struktur standardisiert, mit der Validatoren Blockdaten verteilen und rekonstruieren.

Solana verteilt Blöcke über Turbine. Dabei werden Blockdaten in Shreds zerlegt und über mehrere Ebenen von Validatoren weitergeleitet. Shreds werden zu FEC-Sets (Forward Error Correction) gruppiert. Diese kombinieren Daten-Shreds mit Coding-Shreds, die Wiederherstellungsinformationen enthalten. Bei einem korrekt aufgebauten Set aus 32 Daten- und 32 Coding-Shreds kann ein Empfänger die ursprünglichen Daten aus 32 beliebigen der 64 Shreds rekonstruieren. Das erhöht die Toleranz gegenüber Paketverlusten.

Jeder Shred enthält außerdem einen Merkle-Beweis, der ihn mit der Merkle-Root des Sets verknüpft. Diese wird durch die Signatur des Leaders authentifiziert. Bei einem Set aus 64 Shreds umfasst dieser Beweis sechs Einträge. Sie entsprechen den sechs Ebenen zwischen einem Blatt und der Root. Agaves Prüfung der Beweisgröße verlangt die für diese feste 32:32-Struktur erwartete Größe.

Clients erzeugen bereits 32 Daten-Shreds und 32 Coding-Shreds pro Set. Empfangende Validatoren haben in der Vergangenheit jedoch flexiblere Konfigurationen akzeptiert. SIMD-0317 schließt diese Lücke und macht die feste 32:32-Struktur zur Protokollanforderung. Das vereinfacht die Validierung: Ein Empfänger kann die gültigen Grenzen für Shred-Indizes bestimmen, ohne auf einen Coding-Shred warten zu müssen, der die Abmessungen des Sets offenlegt.

Die feste Struktur vereinfacht auch das Erkennen von Äquivokation, bei der ein Leader widersprüchliche Versionen derselben Daten verteilt. Zwei Shreds, die zum selben FEC-Set gehören, aber unterschiedliche Merkle-Roots und gültige Leader-Signaturen haben, belegen diesen Konflikt. Die Standardisierung des Formats reduziert somit die Komplexität der Implementierung und erleichtert zugleich die Erkennung von Äquivokation.

Inaktive Stakes aus der Berechnung von Belohnungen entfernen

Im Release-Zyklus von Agave 4.4 wird ein Feature Gate für SIMD-0599: Inaktive Stakes aus Stake-Delegationen entfernen aktiviert. Dies vereinfacht, wie Validatoren zu Beginn jeder Epoche inaktive Stake-Accounts bei partitionierten Epochenbelohnungen behandeln. Inaktive Stake-Accounts können SOL oberhalb ihres rentbefreiten Mindestbetrags enthalten, haben jedoch keinen aktiven oder in der Aktivierung befindlichen Stake. Ihre SOL sind nicht delegiert oder haben die Deaktivierung vollständig abgeschlossen.

Diese Accounts erhalten keine Protokollbelohnungen. Ihre Einbeziehung kann jedoch die Anzahl der Partitionen für die Verteilung von Belohnungen und den zur Nachverfolgung des Account-Zustands verwendeten Lattice-Hash beeinflussen. Jeder Validator-Client muss dieses Verhalten exakt reproduzieren. Das erhöht unnötig die Komplexität von konsenskritischem Code.

Die Änderung schließt Stakes aus, die während der belohnten Epoche inaktiv waren. Stakes in Aktivierung, aktive Stakes und Stakes in Deaktivierung bleiben enthalten. Ein Stake-Account, der zu Beginn einer neuen Epoche inaktiv wird, erhält somit weiterhin die Belohnungen aus der vorherigen Epoche, in der er deaktiviert wurde.

Weitere Rent-Reduzierung

Agave 4.4 wird voraussichtlich die letzten drei Aktivierungen der schrittweisen Rent-Reduzierung von Solana einführen. Gemäß dem in SIMD-0437 festgelegten Plan sinkt das erforderliche Mindestguthaben pro Byte Account-Speicher in fünf Schritten von ursprünglich 6.960 auf 696 Lamports. Das entspricht einer Reduzierung um 90 %.

Jede Aktivierung hat ein eigenes Feature Gate. So kann das Netzwerk die Auswirkungen auf die Erstellung von Accounts und das Wachstum des Zustands bewerten, bevor es fortfährt.

Die Senkung dieser Anforderung reduziert das Kapital, das Entwickler und Nutzer beim Erstellen von Token-Accounts, PDAs und anderem Onchain-Zustand binden müssen. Das ist besonders für Anwendungen nützlich, die die Account-Erstellung für ihre Nutzer finanzieren, etwa große Zahlungsdienste.

Schätzungen von Ghost zufolge können mehr als 3 Millionen SOL (~300 Mio. US-Dollar) zurückgefordert werden. Mehrere Tools wurden entwickelt, mit denen Nutzer überschüssige SOL aus ihren Accounts zurückfordern können.

Fazit

Die wichtigsten Änderungen in Agave 4.4 bauen auf Alpenglow auf und treiben lang erwartete Verbesserungen bei Staking-Belohnungen, der Programmbereitstellung und den Account-Kosten voran. Zusammen unterstützen sie Solanas Entwicklung hin zu einem schnelleren und zugänglicheren Netzwerk. Als Nächstes folgen Breakpoint London und anschließend Agave 4.5.

Weitere Ressourcen

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