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

Einführung

Agave v3.1, die neueste Entwicklungsstufe des Solana-Clients Agave, ist da! Dieses Update bringt zahlreiche Verbesserungen für die Client-Performance, den Validator-Betrieb und die Developer Experience. Es aktiviert außerdem mehrere wichtige Feature Gates. Sie schaffen die Grundlage für die protokollinterne Verteilung von Block-Rewards, deutliche Senkungen der State Bonds (also der Rent) und vor allem für das kommende Konsens-Upgrade Alpenglow.

Wichtige Neuerungen in Agave 3.1

• Weniger Festplatten-I/O während des Replay
• Schnellere Client-Neustarts
• Doppelt so schnelle Transaktionsverarbeitung
• Höhere Limits für CPI Account Infos*
• Validator Vote Account V4 und verzögerte Provisionsänderungen*
• Weniger Turbine-ChaCha-Runden*
• Neuer Instruction-Data-Pointer*
• RPC-Verbesserungen

* Upgrade hinter einem Feature Gate

Ob du einen Validator betreibst oder entwickelst: Dieser Leitfaden liefert dir alle Neuerungen und Einblicke, die du brauchst, um die aktuellen Verbesserungen optimal zu nutzen. Jeder Abschnitt dieses Artikels ist eigenständig, sodass du dich auf die für dich wichtigsten Themen konzentrieren kannst. 

Zum Zeitpunkt der Veröffentlichung gilt Agave 3.1.8 als Mainnet Upgrade Candidate (MUC). Anza sucht Freiwillige, die dabei helfen, das Release auf 25 % des Stakes zu bringen. Validatoren: Es ist Zeit für das Upgrade!

Performance-Steigerungen des Clients

Dieses große Agave-Release bringt zahlreiche Performance-Steigerungen. Im Folgenden stellen wir einige der wichtigsten Verbesserungen vor.

Weniger Festplatten-I/O während des Replay 

Agave 3.1 reduziert die Festplattenaktivität während des Replay erheblich. Das folgende Bild zeigt ein 10-sekündiges Profiling-Fenster des Replay, in dem Agave 3.0 echte Mainnet-Transaktionen verarbeitet. Die Festplattenoperationen (als rote Markierungen dargestellt) überschreiten 1.100 Ereignisse. Das ist problematisch, weil jeder Festplattenzugriff I/O-Wartezeit verursacht und dadurch sowohl beim Banking als auch beim Replay für Schwankungen sorgt. 

Mit Agave 3.1 sinkt der Festplatten-I/O während des Replay drastisch. Im selben 10-sekündigen Fenster finden weniger als 80 Festplattenoperationen statt – ein Rückgang um 93 %. Das stabilisiert das Replay, verringert den Verschleiß und verlängert die Lebensdauer der Festplatten.

Schnellere Client-Neustarts

Client-Neustarts werden weiterhin deutlich schneller, vor allem dank Optimierungen an AccountsDB. Bei Hauptversionen von Agave 1.* dauerten Neustarts üblicherweise mehr als 30 Minuten. Agave-2.*-Releases verkürzten diese Zeit auf unter 10 Minuten. Mit Agave 3.1 sinkt sie noch weiter und liegt jetzt meist unter einer Minute. Die nächste Hauptversion, Agave 4.0, soll Neustarts auf unter 30 Sekunden verkürzen. Das verbessert die Verfügbarkeit der Validatoren weiter und reduziert die Wiederherstellungszeit nach Wartungsarbeiten oder unerwarteten Ausfällen.

Schnellere Transaktionsverarbeitung

Agave 3.1 enthält wichtige Fehlerbehebungen, die die Effizienz der Transaktionsverarbeitung deutlich steigern. Zuvor führten Fehler in der Pipeline dazu, dass Banking-Worker übermäßig viel Zeit mit der Synchronisierung mit Proof of History verbrachten, statt Transaktionen auszuführen. Im Leader-Modus plante der Client deshalb während etwa 61 % der Zeit keine Transaktionen aktiv ein.

Nachdem diese Probleme in Agave 3.1 behoben wurden, verbringen die Banking-Worker-Threads jetzt ~91 % ihrer Zeit mit der Transaktionsverarbeitung. Dadurch werden Transaktionen doppelt so schnell verarbeitet. Das steigert den Durchsatz deutlich und nutzt die Leader-Zeit besser aus.

Weitere erwähnenswerte Performance-Verbesserungen sind, dass der Accounts-Index jetzt standardmäßig vollständig im Arbeitsspeicher bleibt. Auch Übergänge an Epochengrenzen wurden deutlich verbessert und sind jetzt in weniger als 400 ms abgeschlossen, statt zuvor mehr als zwei Sekunden zu dauern. Dadurch werden beim Epochenwechsel deutlich weniger Slots übersprungen.

Härtung des Netzwerks

Anza investiert intensiv in die Widerstandsfähigkeit des Agave-Clients – mit kontinuierlichen Stresstests, Red Teaming und Echtzeitüberwachung. Die Details dieser Arbeit wurden bisher vertraulich behandelt. Das Programm ist inzwischen jedoch so ausgereift, dass diese wichtige Arbeit öffentlich gemacht werden kann. Ein eigenes Invalidator-Team bei Anza greift das öffentliche Solana-Testnet stündlich mit neuen Tests an. 

Die Tests fallen in zwei Hauptkategorien. Die erste konzentriert sich auf Denial-of-Service-Szenarien auf Netzwerkebene und prüft den Umgang mit Backpressure sowie die Lastabweisung unter Extrembedingungen. Bei der zweiten Art von Tests werden gezielt zusammengestellte Blöcke mit ungewöhnlichen und gegnerischen Transaktionen erzeugt, die die Solana VM an ihre Grenzen bringen sollen.

Anza entwickelt systematisch Angriffsszenarien und entsprechende Abwehrmaßnahmen. Diese Arbeit basiert auf realistischen Bedrohungsmodellen: Was könnte ein böswilliger, gut informierter Validator mit angemessenem Stake tun? Und was könnte ein externer, gut finanzierter und technisch versierter Entwickler versuchen?

Wie gut diese Vorbereitung funktioniert, zeigte sich im Dezember: Solana hielt einem massiven, wochenlangen DDoS-Angriff stand, der Berichten zufolge einen Spitzenwert von fast 6 Tbps erreichte. Damit war er einer der größten jemals dokumentierten Angriffe auf ein verteiltes System. Trotz des enormen Umfangs zeigte das Netzwerk kaum messbare Auswirkungen. Während des gesamten Angriffs blieben die Bestätigungen im Subsekundenbereich und die Slot-Latenz stabil.

Höhere Limits für CPI Account Infos

SIMD-0339: CPI-Account-Info-Limit erhöhen soll im Verlauf des Agave-3.1-Release-Zyklus im Mainnet aktiviert werden. Dadurch steigt das Limit für Account Infos bei Cross-Program Invocations (CPI) um fast das Vierfache: von 64 auf 255. Das behebt ein seit Langem bestehendes Problem für Entwickler, deren Programme große Account-Listen über CPIs übergeben müssen. Account Infos sind serialisierte Account-Metadaten, die an CPI-Syscalls übergeben werden. So kann das aufgerufene Programm die vom Aufrufer bereitgestellten Accounts lesen.

Bisher waren CPIs auf nur 64 Account Infos pro Syscall beschränkt. Diese Einschränkung zwingt Programme dazu, Account-Listen vor CPI-Aufrufen zu deduplizieren und neu aufzubauen. Das erhöht die Komplexität und den Overhead. In der Praxis überschreiten viele reale Programme diesen Grenzwert regelmäßig, etwa Wrapper für DEX-Aggregatoren wie DFlow oder Jupiter.

Neben der Erhöhung des Limits führt dieses Feature Gate Änderungen an den Compute-Unit-Kosten ein. Diese skalieren mit der Anzahl der Account Infos und Instruction Accounts, die an eine CPI übergeben werden. So bleibt der Anreiz für Programme erhalten, möglichst wenige Accounts zu verwenden. 

Da das Limit lediglich erhöht wird, ist die Änderung vollständig abwärtskompatibel und beeinflusst das Verhalten bestehender Programme nicht.

Validator Vote Account V4 und verzögerte Provisionsänderungen

Zwei Updates hinter Feature Gates, die während des Agave-3.1-Release-Zyklus aktiviert werden sollen, sind für Validator-Betreiber besonders wichtig. Das erste ist SIMD-0185: Vote Account V4. Es führt eine neue Version des Vote-Account-Zustands ein, um kommende Protokoll-Upgrades wie Alpenglow, die Verteilung von Block-Einnahmen und Verbesserungen bei Provisionen zu ermöglichen.

Derzeit speichern Vote Accounts nur einen einzigen Provisionssatz. Mit der kommenden Möglichkeit, Block-Einnahmen gemäß SIMD-0123: Verteilung von Block-Einnahmen protokollintern zu verteilen, müssen Validatoren jedoch separate Provisionssätze für verschiedene Einnahmequellen festlegen können.

Außerdem werden derzeit alle Einnahmen aus Blockgebühren, einschließlich Basis- und Prioritätsgebühren, auf das Identity Account des Validators eingezahlt. Das kann betriebliche und sicherheitsrelevante Probleme verursachen. Das Identity Account kann kein Cold Wallet sein, da es häufig Nachrichten für wichtige Netzwerkprotokolle wie Turbine und Gossip signieren muss.

Vote Account V4 beseitigt diese Einschränkungen, indem es den Vote State um neue Felder erweitert (siehe Codeblock unten). Damit können Validatoren sowohl den Provisionssatz als auch das Collector Account für Inflations-Rewards und Block-Einnahmen konfigurieren. Das Update entfernt außerdem das veraltete Feld prior_voters.

pub struct VoteStateV4 {
    pub node_pubkey: Pubkey,
    pub authorized_withdrawer: Pubkey,

    /// REMOVED
    /// commission: u8,

    /// NEW: the collector accounts for validator income
    pub inflation_rewards_collector: Pubkey,
    pub block_revenue_collector: Pubkey,

    /// NEW: basis points (0-10,000) that represent how much of each income
    /// source should be given to this VoteAccount
    pub inflation_rewards_commission_bps: u16,
    pub block_revenue_commission_bps: u16,

    /// NEW: reward amount pending distribution to stake delegators
    pub pending_delegator_rewards: u64,

    /// NEW: compressed bls pubkey for alpenglow
    pub bls_pubkey_compressed: Option<[u8; 48]>

    pub votes: VecDeque<LandedVote>,
    pub root_slot: Option<Slot>,

    /// UPDATED: serialization structure of the AuthorizedVoters map is
    /// unchanged but will now contain entries for the previous epoch.
    pub authorized_voters: AuthorizedVoters,

    /// REMOVED
    /// prior_voters: CircBuf<(Pubkey, Epoch, Epoch)>,

    pub epoch_credits: Vec<(Epoch, u64, u64)>,
    pub last_timestamp: BlockTimestamp,
}

Im Rahmen des Updates werden Provisionswerte in Basispunkten gespeichert. Die bestehende Instruction UpdateCommission im Vote Program unterstützt jedoch nur ganzzahlige Prozentwerte für Provisionen. Bis SIMD-0291: Provisionssatz in Basispunkten umgesetzt ist, bleiben Provisionssätze auf ganze Prozentwerte beschränkt. Provisionsberechnungen sollten daher vorerst weiterhin ganzzahlige Prozentwerte verwenden.

Bestehende Tools oder Programme, die den Vote State lesen, einschließlich des Stake Program, werden aktualisiert, um die neue Vote-Account-Version zu unterstützen.

Verzögerte Provisionsänderungen

Das zweite für Validator-Betreiber wichtige Update hinter einem Feature Gate ist SIMD-0249: Provisionsänderungen verzögern. Durch diese Änderung können Validatoren jederzeit Provisionsänderungen einreichen. Sie treten jedoch frühestens nach Ablauf einer vollständigen Epoche in Kraft.

Das Vote Program wird so geändert, dass die aktuelle Einschränkung entfällt, die Provisionserhöhungen in der ersten Hälfte einer Epoche verhindert. Statt den Zeitpunkt für das Einreichen einer Provisionsänderung einzuschränken, erzwingt das Protokoll eine Verzögerung bis zu ihrer Aktivierung. Validatoren können ihre Provisionssätze damit frei anpassen, müssen jedoch mindestens eine vollständige Epoche warten, bevor der neue Satz gilt.

Diese Verzögerung hilft auch Stake-Delegatoren, da sie eine vollständige Epoche Zeit haben, auf bevorstehende Provisionsänderungen zu reagieren. Vor allem verhindert sie „Commission Rugging“. Dabei erhöhen böswillige Validatoren ihre Provision kurz vor einer Epochengrenze vorübergehend auf 100 %, um Rewards abzuschöpfen, und setzen sie kurz danach schnell wieder auf den normalen Wert zurück.

Senkung der State Bonds (Rent)

Hohe Anforderungen an State Bonds, üblicherweise als „Rent“ bezeichnet, gehören weiterhin zu den wichtigsten langfristigen Skalierungshürden für Solana-Entwickler. State Bonds im Mainnet sind derzeit teuer: Die Speicherung kostet etwa 1 Million US-Dollar pro Gigabyte. Das Erstellen eines einzelnen neuen Token Accounts (ATA) erfordert beispielsweise etwas mehr als 0,002 SOL, was zu aktuellen Preisen ungefähr 0,25 US-Dollar entspricht. Dadurch werden direkte Token-Airdrops in großem Maßstab unerschwinglich. Auch Micropayments und Stablecoin-Zahlungsanwendungen werden erschwert, da sie entweder die Erstellung von Token Accounts bezuschussen oder diese Kosten an die Endnutzer weitergeben müssen.

Ein erster Schritt zur Senkung dieser Belastung ist SIMD-0194: Rent-Exemption-Grenzwert außer Betrieb nehmen, dessen Aktivierung für den Agave-3.1-Release-Zyklus vorgesehen ist. Damit beginnt eine umfassendere Initiative, die Speicherkosten deutlich zu senken und zu vereinfachen. Anwendungen können dadurch auf Millionen Nutzer skalieren, ohne dass untragbare Kapitalanforderungen für den State entstehen. Zusätzlich befinden sich derzeit drei weitere SIMDs in Vorbereitung, die direkt auf die Kosten von State Bonds abzielen und die Rent weiter senken sollen.

SIMD-0194 vereinfacht zukünftige Rent-Updates. Derzeit ist die Berechnung, ob ein Account von der Rent befreit ist, für On-Chain-Programme relativ teuer. Die aktuelle Berechnung `Rent::minimum_balance` verwendet Gleitkommaarithmetik (f64) und verbraucht etwa 256 Compute Units pro Aufruf. Mit SIMD-0194 sinkt dieser Wert auf nur 8 CUs, da die Gleitkommaoperationen aus der Rent-Exemption-Logik entfernt werden.

Dazu wird das Feld exempt_threshold (f64) außer Betrieb genommen. Programme müssen dann keine Gleitkommaberechnungen mehr ausführen, um den Rent-Exemption-Status zu ermitteln.

Im Rahmen der Änderung wird lamports_per_byte_year in lamports_per_byte umbenannt und der Standardwert von 3480 auf 6960 verdoppelt. Das berücksichtigt, dass die Rent-Befreiung historisch als Guthaben in Höhe von zwei Jahresmieten definiert wurde. Wichtig: Dieses Update ändert nicht den Betrag, der für die Rent-Befreiung eines Accounts erforderlich ist. Es vereinfacht und standardisiert lediglich die Darstellung und Berechnung des Werts.

Das Update ist vollständig abwärtskompatibel und hat keine Auswirkungen auf bereits bereitgestellte Programme.

Ausblick: SIMD-0437

Von den zusätzlichen Rent-bezogenen SIMDs, die im weiteren Jahresverlauf erwartet werden, ist SIMD-0437: `lamports_per_byte` schrittweise auf 696 senken am bedeutendsten. Dieser Vorschlag beschreibt einen strukturierten Zeitplan, um die langfristigen Kosten für State Bonds zu senken. Dazu wird `lamports_per_byte` schrittweise von 6960 auf 696 reduziert – eine Senkung um den Faktor 10.

SIMD-0437 ersetzt den früheren Vorschlag SIMD-0436, der eine einmalige Senkung um 50 % vorsah. Stattdessen führt SIMD-0437 einen differenzierteren fünfstufigen Reduktionsplan ein: 6333 → 5080 → 2575 → 1322 → 696.

Durch die Aufteilung in mehrere Phasen kann das Netzwerk das Wachstum des States im Zeitverlauf beobachten und bewerten. Gleichzeitig werden die umstrittensten Senkungen in getrennte Schritte aufgeteilt, damit sie klarer diskutiert und abgestimmt werden können.

Weitere wichtige Updates im Agave-3.1-Release-Zyklus

Strikte Durchsetzung von 32 Data Shreds und 32 Coding Shreds

Derzeit akzeptiert Turbine eine variable Anzahl von Shreds pro FEC-Set. Dieses Verhalten erhöht unnötig die Komplexität, ohne nennenswerte Vorteile zu bieten. Die Validierung von Shred-Indizes wird schwieriger, da Empfänger die Coding Shreds benötigen, um die Indexgrenzen zu bestimmen. Die bevorstehende Aktivierung des Feature Gates für SIMD-0317: 32 Data Shreds + 32 Coding Shreds erzwingen standardisiert dieses Verhalten: Pro FEC-Set sind dann genau 32 Data Shreds und 32 Coding Shreds erforderlich. Die Änderung verbessert außerdem die Erkennung von Equivocation. Diese wird später in Durchsetzungsmechanismen wie Slashing-Strafen einfließen.

Statische Instruction-Limits

Derzeit bestehen Transaktionen mit mehr als 64 Top-Level-Instructions die anfänglichen Sanitization-Prüfungen, schlagen aber zur Laufzeit fehl. Das verursacht unnötige Arbeit für den Scheduler, weil garantiert fehlschlagende Transaktionen in die Pipeline gelangen und Scheduler-Ressourcen verbrauchen.

Die bevorstehende Aktivierung des Feature Gates für SIMD-0160: Statisches Instruction-Limit behebt dieses Problem, indem das Limit von 64 Instructions bereits bei der Transaction Sanitization durchgesetzt wird. Nach dieser Änderung schlägt die Sanitization jeder Transaktion mit mehr als 64 Top-Level-Instructions (einschließlich CPI-Aufrufen) fehl. Die Transaktion wird sofort abgelehnt.

Weniger Turbine-ChaCha-Runden

SIMD-0332: ChaCha-Runden für Turbine von 20 auf 8 reduzieren verbessert die Fähigkeit von Turbine, Blockdaten zu verteilen, geringfügig, aber spürbar. Derzeit verwendet Turbine ChaCha20, um nach Stake gewichtete Validatoren beim Aufbau von Bäumen für die Blockverteilung deterministisch zu mischen. Diese zufällige Reihenfolge ist wichtig, um Zensurangriffe zu verhindern, verursacht jedoch zusätzlichen Rechenaufwand.

ChaCha-Runden fungieren als deterministischer Mischer. Jede Runde wendet Transformationen an, um die Ausgabe weiter zu randomisieren. Mehr Runden bieten stärkere kryptografische Sicherheit, erhöhen aber auch die Rechenkosten.

Seit Agave auf XDP umgestellt wurde, erfolgen Retransmit-Sends nahezu sofort. Dadurch dominiert nun der gewichtete Mischvorgang die Laufzeit. Bei etwa ~1 Mikrosekunde pro Shred bleibt der Prozess ausreichend randomisiert und resistent gegen Zensur, wenn ChaCha20 auf ChaCha8 reduziert wird. Zugleich wird verhindert, dass er zum Engpass wird.

Neuer Instruction-Data-Pointer

Derzeit müssen sBPF-Programme den Accounts-Abschnitt des serialisierten Eingabebereichs parsen, um Instruction Data zu finden. Da im Serialisierungslayout die Accounts vor den Instruction Data stehen, müssen Programme jeden Account-Eintrag durchlaufen, bevor sie das Instruction-Data-Segment erreichen. Das verursacht unnötigen Aufwand für Programme, die hauptsächlich oder ausschließlich mit Instruction Data arbeiten.

Die bevorstehende Aktivierung des Feature Gates für SIMD-0321: Instruction-Data-Pointer in VM-Register 2 verbessert dies durch einen 64-Bit-Pointer auf Instruction Data im VM-Register r2 am Programmeinstiegspunkt. Dieser Pointer verweist direkt auf den Anfang des Instruction-Data-Abschnitts im Eingabebereich. Programme können so sofort auf Instruction Data zugreifen, ohne zunächst den Accounts-Abschnitt zu parsen. Weil der Parsing-Overhead entfällt, sinkt der Verbrauch von Compute Units.

Kompatibilitätshinweis: Diese Funktion ist nur für Programme abwärtskompatibel, die am Einstiegspunkt derzeit nicht aus r2 lesen. Programme, die sich fälschlicherweise auf den zuvor in r2 vorhandenen nicht initialisierten oder ungültigen Wert verlassen, funktionieren nach Aktivierung dieser Funktion nicht mehr.

RPC-Verbesserungen

Der RPC-Endpunkt getProgramAccounts gibt jetzt korrekte JSON-RPC-Fehler zurück, wenn fehlerhafte Filter übergeben werden. Bisher wurden ungültige Filter stillschweigend ignoriert. Dadurch fiel der RPC-Aufruf auf eine ungefilterte Abfrage zurück, die häufig unerwartet teure Requests und unnötige Last auf RPC-Nodes verursachte. Mit dieser Verbesserung geben fehlerhafte Filter nun eine klare Fehlermeldung zurück. Das verhindert versehentlich ressourcenintensive Abfragen und erleichtert das Debugging erheblich.

Außerdem werden Fehler bei der Signaturprüfung in simulateTransaction() und in der Preflight-Phase von sendTransaction() jetzt als TransactionError::SignatureFailure im Feld err des Simulationsergebnisses zurückgegeben, statt als JSON-RPC-API-Fehler (-32003) ausgelöst zu werden.

Anwendungen, die Fehler bei der Signaturprüfung bisher durch das Abfangen von JSON-RPC-Ausnahmen behandelt haben, sollten diese Fehler daher jetzt direkt in der Simulationsantwort erwarten. Anwendungen, die TransactionError-Werte in Simulationsergebnissen bereits materialisieren und verarbeiten, können an diesen Prüfpunkten nun mit TransactionError::SignatureFailure rechnen.

Fazit

Agave v3.1 ist ein umfangreiches Client-Upgrade mit zahlreichen Performance-Steigerungen und Optimierungen. Dazu gehören weniger Festplatten-I/O, eine schnellere Transaktionsverarbeitung und eine bessere RPC-Fehlerbehandlung. Agave hat zudem deutliche Fortschritte bei der Härtung des Netzwerks erzielt und ist unter gegnerischen Bedingungen widerstandsfähiger. Dieses Release markiert außerdem den ersten Schritt hin zu einer deutlichen Senkung der State Bonds.

Anza hebt sich weiterhin als einziges Core-Entwicklungsteam der Branche ab, das Verbesserungen für den gesamten Stack ausliefert – bis hin zur Einreichung von Patches für den Linux-Kernel. Agave 3.1 wird das Netzwerk schon bald antreiben. Solana beweist damit erneut seine Skalierbarkeit.

Der nächste Meilenstein ist Agave 4.0 und der Testnet-Start von Alpenglow, der derzeit für Anfang Mai geplant ist.

Weitere Ressourcen

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