Agave 4.2 Update: Alles, was du wissen musst

Einführung

Mit Agave 4.2 erschließt der zentrale Validator-Client von Solana erneut Neuland. Das große Release konzentriert sich auf drei lang erwartete Upgrades mit Feature Gates: Slot-Zeiten von 200 ms, eine Senkung der State Bonds um 90 % und Transaktionen mit 4.096 Byte durch das neue Transaction-v1-Format. Außerdem enthält es Alpenglow bereits vollständig, bevor es wie geplant im folgenden Release aktiviert wird. Zugleich ist XDP transmit jetzt standardmäßig aktiviert.

Wichtige Updates

• 3,3× größere Transaktionen mit einem neuen Transaction-v1-Standard *
• 90 % niedrigere State Bonds (Rent) *
• Kürzere Slot-Zeiten von 200 ms *
• Alpenglow vollständig implementiert
• Neue Governance-Tools (bezogen auf SIMDs)

* Upgrades mit Feature Gates

Größere Transaktionen (Transaction v1)

Der Release-Zyklus von Agave 4.2 umfasst die Aktivierung eines Feature Gates für größere Transaktionen mit bis zu 4.096 Byte statt des langjährigen Limits von 1.232 Byte. Das höhere Limit ist formell in SIMD-0296: Größere Transaktionsgröße definiert, entspricht einer Steigerung um etwa das 3,3-Fache und gilt ausschließlich für das neue Transaction-v1-Format aus SIMD-0385: Transaction-V1-Format. Legacy- und v0-Transaktionen funktionieren unverändert weiter und unterliegen weiterhin dem bestehenden Limit von 1.232 Byte.

Für Entwickler bedeutet das mehr als zusätzlichen Platz für Instruction-Daten. Kryptografische Beweise, Multisig-Freigaben, große Account-Listen und andere Payloads, die bisher nicht in eine einzelne Transaktion passten, können nun in einer einzigen protokollnativen atomaren Operation ausgeführt werden. Die Änderung erhöht nicht die Limits von Solana für Compute, Accounts, Signaturen oder die Anzahl der Instructions.

Das ursprüngliche Limit von 1.232 Byte stammt aus der früheren Netzwerkarchitektur von Solana. Transaktionen wurden als einzelne UDP-Datagramme übertragen und mussten in die minimale Maximum Transmission Unit (MTU) von IPv6 mit 1.280 Byte passen. Nach Abzug des 40 Byte großen IPv6-Headers und des acht Byte großen UDP-Headers blieben 1.232 Byte für die Transaktion selbst. Jede Transaktion in einem einzigen Paket zu halten, reduzierte die Fragmentierung und machte die Übertragung vorhersehbarer.

Solana ist für die Transaktionsannahme längst von UDP zu QUIC gewechselt. QUIC-Streams sind nicht auf die Payload eines einzelnen Netzwerk-Datagramms beschränkt. Daher ist die alte Obergrenze von 1.232 Byte nicht mehr erforderlich. Clients benötigen weiterhin eine explizite Obergrenze für Admission Control, Speicherzuweisung und Konsensvalidierung. Diese Grenze kann nun jedoch anhand der Anforderungen von Runtime und Anwendung statt anhand der IPv6-MTU festgelegt werden.

Account-Listen beanspruchen häufig einen erheblichen Teil des verfügbaren Platzes. Jeder öffentliche Ed25519-Schlüssel und jede program-derived address belegt 32 Byte. Eine Transaktion muss zudem jeden Account angeben, den ihre Instructions lesen oder ändern. Dadurch lag die effektive Obergrenze bisher bei ungefähr 32 vollständigen Account-Schlüsseln. Um dies zu umgehen, führten V0-Transaktionen Address Lookup Tables (ALTs) ein. Sie ersetzen jeden 32-Byte-Schlüssel durch einen ein Byte großen Tabellenindex und ermöglichen Transaktionen so, das Runtime-Limit von 64 Accounts zu erreichen.

ALTs sind zwar eine effektive Form der Komprimierung, bringen aber leider zusätzliche Komplexität mit sich. Anwendungen müssen Lookup-Tabellen onchain erstellen und verwalten. RPC-Dienste und Indexer, die eine rohe v0-Nachricht decodieren, müssen deren vollständige Account-Liste anhand von Transaktionsmetadaten oder dem jeweiligen Tabellenstatus rekonstruieren. Das erschwert das Parsen von Transaktionen, die auf eine ALT verweisen, die inzwischen geschlossen wurde und onchain nicht mehr verfügbar ist. 

V1-Transaktionen lösen dieses Problem für Entwickler. Sie sind groß genug, um den vollständigen Account-Satz aufzunehmen, der derzeit durch ALTs unterstützt wird: 64 vollständige öffentliche Schlüssel mit insgesamt 2.048 Byte. Eine Anwendung, die von v0 migriert, kann daher ihre Lookup-Tabelleneinträge auflösen und die resultierenden Adressen direkt in eine v1-Transaktion aufnehmen.

Transaktionsgrößen von 1.232 Byte sind außerdem besonders einschränkend für kryptografische Funktionen wie Zero-Knowledge-Beweise und BLS-Implementierungen ohne native Precompiles. Diese Workloads können Hunderte oder Tausende Byte an Beweis- oder Signaturdaten enthalten. Eine Obergrenze von 4.096 Byte deckt viele dieser gängigen kryptografischen Anwendungsfälle ab. 

Spezifikation von Transaction V1

Eine serialisierte v1-Transaktion beginnt mit dem Versionsbyte 0x81. Darauf folgen ein drei Byte großer Message-Header im Legacy-Stil, eine 32-Bit-Konfigurationsmaske für die Transaktion, ein 32 Byte großer Gültigkeitsspezifizierer, die Anzahl der Instructions und Adressen, das vollständige Array aus 32 Byte großen Adressen, Konfigurationswerte, Instruction-Header mit fester Größe, zusammenhängende Instruction-Payloads und schließlich die Signaturen. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

Instruction-Header geben explizit den Index des Programm-Accounts, die Anzahl der Instruction-Accounts und die Länge der Instruction-Daten an. Dadurch sind die Nachrichtengrenzen verfügbar, ohne die Payload jeder Instruction interpretieren zu müssen.

V1-Transaktionen bleiben auf 12 Signaturen, 64 Account-Adressen, 64 Instructions und 255 Account-Indizes pro Instruction beschränkt. Große Transaktionen müssen weiterhin innerhalb des angeforderten Compute-Unit-Limits, des Limits für geladene Account-Daten, der Regeln für Account-Sperren und der verfügbaren Ausführungskapazität des Blocks liegen.

Bestehende Parser können v1 nicht einfach wie v0 mit einer größeren Maximallänge behandeln. Indexer, RPCs, SDKs und Signaturinfrastruktur, die serialisierte Transaktionen untersuchen, müssen das Präfix 0x81 erkennen und die neue Feldreihenfolge implementieren. Besonders wichtig: Bei v1 stehen die Signaturen am Ende der Transaktion und nicht wie bei Legacy- und v0-Transaktionen vor der Nachricht.

Transaction v1 ersetzt Konfigurations-Instructions des Compute Budget Program durch Felder im Transaktions-Header. Das anfängliche `TransactionConfigMask` kann Folgendes für die Transaktion deklarieren:

• gesamte Priority Fee in Lamports
• Compute-Unit-Limit
• Größenlimit für geladene Account-Daten
• angeforderte Heap-Größe

Jedes gesetzte Bit kennzeichnet einen zugehörigen vier Byte großen Konfigurationswert. Die 64-Bit-Priority-Fee belegt zwei Positionen in der Maske. Die Maske ist so ausgelegt, dass sie in zukünftigen Transaktionsversionen erweitert werden kann.

Senkung der State Bonds (Rent)

Hohe Anforderungen an State Bonds, üblicherweise als „Rent“ bezeichnet, gehören weiterhin zu den größten Hürden von Solana für Anwendungen mit vielen Accounts. Der Name ist etwas irreführend, denn Rent ist keine wiederkehrende Speichergebühr, sondern eine rückzahlbare Kaution. Ein Account muss sie halten, solange sein Status onchain bleibt. Die Lamports können normalerweise zurückgewonnen werden, wenn der Account geschlossen wird. Bis dahin handelt es sich jedoch um Kapital, das ein Entwickler oder Nutzer im Voraus bereitstellen und gebunden lassen muss.

Agave 4.2 führt die durch ein Feature Gate gesteuerte Implementierung von SIMD-0437: lamports_per_byte schrittweise auf 696 senken ein. Sie senkt die Konstante `lamports_per_byte` von 6.960 auf 696. Das entspricht einer Senkung der Rent um 90 % – genauer gesagt des rentenfreien Mindestbetrags. Die Umstellung erfolgt über fünf unabhängige Feature Gates: 6.960 → 6.333 → 5.080 → 2.575 → 1.322 → 696. 

Wenn eines der Gates aktiviert wird, aktualisiert Agave die Rent-Konfiguration der Bank und veröffentlicht den neuen Wert über die Rent-Sysvar. Durch die schrittweise Einführung kann das Netzwerk beobachten, wie Anwendungen auf jedes Preisniveau reagieren. Es kann die nächste Senkung stoppen, falls das Statuswachstum oder die Ressourcennutzung der Validatoren Anlass zur Sorge gibt.

Der rentenfreie Mindestbetrag eines Accounts wird aus der zugewiesenen Datengröße und einem festen Speicher-Overhead von 128 Byte berechnet:

minimum_balance = (128 + account_data_size) × lamports_per_byte

Der Rent-Mechanismus selbst ändert sich dadurch nicht: Accounts benötigen weiterhin ein Mindestguthaben, das beim Schließen des Accounts zurückgewonnen werden kann. Es ändert sich nur die Menge an SOL, die gebunden werden muss.

Ein standardmäßiger SPL-Token-Account ist 165 Byte groß. Einschließlich des Overheads von 128 Byte beträgt seine effektive Größe daher 293 Byte. Durch die Senkung der Rent um 90 % sinkt der für einen solchen Account erforderliche SOL-Betrag von etwa ~0,16 $ auf weniger als 2 Cent. 

Das hat besonders wichtige Folgen für Stablecoin-Zahlungen, Token-Verteilungen, Treueprogramme und direkte Airdrops. Eine Wallet hält SPL-Tokens nicht direkt. Sie benötigt normalerweise für jeden Mint einen Associated Token Account (ATA). Wenn ein Empfänger noch nicht über den erforderlichen ATA verfügt, kann der Absender ihn zusammen mit der Übertragung erstellen. Er muss jedoch auch das rentenfreie Guthaben des Empfängers finanzieren. Dabei handelt es sich in der Regel um einmalige Onboarding-Kosten für jedes Wallet-und-Mint-Paar und nicht um Kosten, die bei jeder späteren Zahlung anfallen. In großem Maßstab können sie dennoch darüber entscheiden, ob ein Unternehmen das Onboarding subventioniert oder die Kosten an die Nutzer weitergibt.

Statuswachstum von Solana

Die schrittweise Senkung ist wichtig, da ein niedrigerer State Bond auch den Betrag reduziert, den ein Angreifer binden muss, um unerwünschten Status zu erzeugen und dauerhaft zu erhalten. Der Solana-Status wird repliziert, indexiert, in Snapshots aufgenommen und von jedem Validator verwaltet. Daher wirkt sich dauerhaftes Statuswachstum letztlich auf den Speicherbedarf, AccountsDB-Operationen und die Betriebskosten aus.

Laut einer aktuellen Analyse der Solana Foundation belegen die Speicherdateien von AccountsDB bei einer empfohlenen Zuweisung von 1 TB etwa 495 GB. Nach der geplanten Rent-Senkung müsste ein Angreifer SOL im Wert von etwa 17,2 Millionen US-Dollar einsetzen, um den verbleibenden Speicher auszuschöpfen. Wird die empfohlene Speicherzuweisung für Validatoren auf 2 TB verdoppelt, steigt der erforderliche Kapitaleinsatz des Angreifers auf 51 Millionen US-Dollar.

Unter Berücksichtigung neu erstellter und geschlossener älterer Accounts wächst der Status den Ergebnissen zufolge um etwa 0,3 GB pro Tag.

Ein in Epoche 997 erstellter Status-Snapshot zeigt, dass sich die Statusnutzung stark konzentriert. SPL-Token-Accounts bildeten die größte Kategorie. OpenBook- und Serum-Accounts belegten rund 30 % des aktiven Status, was die komplexe Architektur von Onchain-Orderbüchern widerspiegelt. Die Analyse schätzt außerdem, dass etwa 30 % des von SPL Token belegten Speicherplatzes mit Assets im Stil des Pump.fun-Token-Launchpads verbunden waren.

Sicherheitsmaßnahmen

Um State Bonds sicher zu senken, muss es einen praktikablen Weg in die Gegenrichtung geben. Ohne zusätzliche Runtime-Änderungen würde eine spätere Erhöhung des rentenfreien Mindestbetrags dazu führen, dass bestehende Accounts sofort unter dem neuen Schwellenwert liegen. Transaktionen, die Schreibsperren für diese Accounts setzen, könnten selbst dann fehlschlagen, wenn sie keinen zusätzlichen Status zuweisen. Das könnte weitreichende Störungen verursachen.

Hier ändert SIMD-0392: Runtime an Rent-Erhöhungen anpassen die Regel für das Mindestguthaben nach der Ausführung, sodass für bestehende Accounts bei steigender Rent Bestandsschutz gelten kann. Wenn ein Account bereits existiert, nicht größer wird und denselben Eigentümer behält, entspricht sein zulässiges Minimum dem niedrigeren der folgenden Werte:

1. Mindestbetrag nach dem aktuellen Rent-Satz
2. Guthaben des Accounts vor der Ausführung

Neue Accounts müssen weiterhin den aktuellen rentenfreien Mindestbetrag erfüllen. Dasselbe gilt für Accounts, die ihren zugewiesenen Speicher vergrößern oder den Eigentümer wechseln. Ein Guthaben von null steht weiterhin für die Schließung des Accounts. So kann ein bestehender Status mit seinem bisherigen gebundenen Betrag weiterarbeiten, während neu zugewiesener Status den neuesten Satz bezahlt.

SIMD-0438: Schutzmaßnahme für eine Erhöhung des rentenfreien Mindestbetrags ergänzt ein separates schützendes Feature Gate, das `lamports_per_byte` auf den bisherigen Wert von 6.960 zurücksetzt. Es soll nur aktiviert werden, wenn die niedrigere Rent übermäßiges Statuswachstum oder ein anderes erhebliches Betriebsproblem verursacht. Da das Gate bereits vor Beginn der Senkungen vorhanden ist, müssen die Kernentwickler nicht mitten in einem sich abzeichnenden Vorfall mit Statuswachstum eine neue Konsensänderung entwerfen, prüfen und bereitstellen.

Zusammen machen die fünf Senkungs-Gates, die Bestandsschutzregeln aus SIMD-0392 und der Fallback aus SIMD-0438 die Einführung auf Protokollebene reversibel. Das Netzwerk kann den Bond schrittweise senken, das Verhalten von aktivem Status und Validator-Speicher beobachten, bei einem Zwischenwert pausieren oder die ursprüngliche Anforderung wiederherstellen, ohne dass jeder bestehende Account sofort aufgestockt werden muss.

Kürzere Slot-Zeiten von 200 ms

Eines der am meisten erwarteten Performance-Upgrades von Solana senkt die angestrebten Slot-Zeiten von 400 ms auf 200 ms. Der wichtigste Vorteil ist eine geringere Latenz. Bei Slots von 200 ms verkürzt sich das Leader-Fenster von Solana mit vier Slots von 1,6 Sekunden auf 800 ms. Das verkürzt Bestätigungszeiten und begrenzt, wie lange ein böswilliger Leader Transaktionen verzögern, neu anordnen oder selektiv aufnehmen kann. Kürzere Slots bieten Anwendungen wie Oracle-Nutzern und Market Makern außerdem eine feinere zeitliche Auflösung onchain.

Der Vorschlag soll die bestehende Ökonomie und den Durchsatz von Solana erhalten. Inflationsparameter, die Kosten des Validator Admission Ticket unter Alpenglow und die Arbeitslimits pro Slot werden proportional angepasst. Sollten die 200-ms-Slots jedoch vor Alpenglow eingeführt werden, könnten sich die Abstimmungskosten der Validatoren ungefähr verdoppeln, da sie doppelt so häufig abstimmen müssten.

Eine ausführlichere Betrachtung der 200-ms-Slots findest du in unserer früheren Analyse zu Agave 4.1.

Weitere wichtige Updates

Während des Release-Zyklus von Agave 4.2 sollen mehrere kleinere, aber wichtige Verbesserungen aktiviert werden.

Bereitschaft für Alpenglow

Agave 4.2 enthält Alpenglow vollständig, aktiviert das neue Konsensprotokoll aber noch nicht im Mainnet. Die zentralen Engineering-Teams nutzen diesen Release-Zyklus für weitere Tests, Audits und Härtungsmaßnahmen, bevor die Konsensmigration voraussichtlich mit Agave 4.3 erfolgt. Validatoren mit Version 4.2 verfügen daher bereits über die vollständige Alpenglow-Implementierung, einschließlich der Votor-Abstimmungs-Engine und ihrer Komponenten zur Verifizierung von BLS-Zertifikaten. 

Um die Sicherheitsprüfung des Codes auszuweiten, veranstaltet Anza außerdem einen Alpenglow-Bug-Bounty-Wettbewerb mit einem Preispool von bis zu 50.000 SOL und einem Einreichungszeitraum vom 5. bis 19. August. Alpenglow war während der Entwicklung, der Monorepo-Migration und interner Audits zuvor vom laufenden Agave-Bounty-Programm ausgeschlossen. Der Wettbewerb macht Alpenglow erstmals für Bountys zugänglich und soll Probleme aufdecken, die bei früheren Prüfungen möglicherweise übersehen wurden.

Stake Program: Gleitkomma zu Festkomma

Der Release-Zyklus von Agave 4.2 umfasst außerdem die durch ein Feature Gate gesteuerte Implementierung von SIMD-0391: Stake Program von Gleitkomma auf Festkomma umstellen. Sie ersetzt die IEEE-754-Gleitkommaarithmetik in den Aufwärm- und Abkühlberechnungen des Stake Program durch deterministische Festkomma-Ganzzahlarithmetik. Hauptgrund ist die Kompatibilität mit der standardmäßigen eBPF-Toolchain, die keine Gleitkommaoperationen unterstützt. Die SBF-Toolchain von Solana kann sie mit deterministischen Soft-Float-Routinen emulieren. Das ist jedoch ineffizient und verhindert die Migration des Stake Program zu einer `no_std`-Implementierung.

Die meisten Anwendungen müssen nicht geändert werden. Indexer und Staking-Tools, die effektiven, aktivierten oder deaktivierten Stake unabhängig berechnen, sollten jedoch nach Aktivierung des Features die neuen Ganzzahlregeln implementieren.

Neue Governance-Tools

Im Release-Zyklus von Agave 4.2 starten außerdem neue Governance-Tools, die seit dem letzten Jahr entwickelt werden. Sie bieten sowohl Validatoren als auch nativen Stakern einen Onchain-Prozess, mit dem sie ihre Position zu wichtigen wirtschaftlichen und protokollweiten Entscheidungen signalisieren können. 

Die zentrale Komponente, svmgov, ist ein Anchor-basiertes Programm. Es verwaltet die Erstellung von Vorschlägen, Unterstützung, nach Stake gewichtete Abstimmungen und den Abschluss. Die Stimmgewichte stammen aus einem epochenspezifischen Stake-Snapshot, den das Node Consensus Network (NCN) erstellt. Unabhängige Betreiber leiten den Snapshot ab, erzielen einen Konsens über eine kanonische Merkle-Root und veröffentlichen sie onchain. Validatoren weisen ihren aktiven Stake anschließend mit Merkle-Beweisen nach. 

Validatoren mit mindestens 100.000 SOL an aktivem Stake können Vorschläge erstellen. Vorschläge benötigen die Unterstützung von 15 % des Cluster-Stakes, bevor sie in den Abstimmungsprozess übergehen. Das Governance-Repository enthält außerdem eine Rust-CLI und ein Web-Frontend für Abstimmungen und die Nachverfolgung der Unterstützung.

Vollständige Vorschlagsdokumente befinden sich im separaten Repository für Solana-Governance-Vorschläge und sind an einen bestimmten Git-Commit gebunden. Der Onchain-Vorschlags-Account speichert hingegen den Link, den Lebenszyklusstatus und die Stimmenauszählung. Validatoren stimmen zunächst mit dem gesamten an sie delegierten Stake ab. Einzelne Delegatoren behalten jedoch die Hoheit über ihre SOL. Ein Staker kann für einen bestimmten Stake-Account eine Überschreibung einreichen. Dadurch wird dieser Stake aus der Stimmenauszählung des Validators entfernt und entsprechend der eigenen Stimme des Stakers neu zugewiesen.

Solana Governance Proposals (SGPs) sollen SIMDs ergänzen und nicht ersetzen: Ein SGP beantwortet die grundsätzliche Frage, ob das Netzwerk eine Änderung verfolgen soll. Das zugehörige SIMD legt fest, wie die Änderung umgesetzt werden soll.

Drei SGPs haben die Unterstützungsphase bereits bestanden und bilden die erste Runde der Governance-Abstimmungen im neuen System:

• SGP-0001: Die Solana-Verfassung schlägt vor, einen kanonischen gesellschaftlichen Governance-Vertrag zu ratifizieren. Er definiert die Rollen von Entwicklern, Validatoren und Stakern und etabliert den SGP-Prozess formell.
• SGP-0002: Doppelte Disinflation fordert das Netzwerk auf, die jährliche Disinflationsrate von SOL von 15 % auf 30 % zu verdoppeln und die endgültige Inflationsrate von 1,5 % unverändert zu lassen. Dadurch verkürzt sich der geschätzte Zeitraum bis zu dieser endgültigen Rate von etwa 5,7 auf 2,8 Jahre. 
• SGP-0003: Ressourcen- und Aufnahmegebühr schlägt vor, die bestehende pauschale Grundgebühr durch eine Aufnahmegebühr von 2.500 Lamports für den Leader und eine separate Ressourcengebühr zu ersetzen. Letztere basiert auf den angeforderten Transaktionskosteneinheiten und wird vollständig verbrannt. Die Verteilung der Priority Fees bleibt unverändert.

Fazit

Agave 4.2 ist eines der folgenreichsten Solana-Releases der letzten Zeit. Schnellere Slots von 200 ms bringen das Netzwerk näher an Reaktionszeiten in Echtzeit. Die geplante Senkung der State Bonds um 90 % macht die Erstellung von Accounts deutlich günstiger. Transaction v1 mit 4.096 Byte schafft wesentlich mehr Platz für komplexe Instructions, kryptografische Beweise und Anwendungen mit vielen Accounts. Zusammen machen diese Änderungen Solana für Entwickler und Nutzer schneller, günstiger und ausdrucksstärker.

Weitere Ressourcen

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