Solana Agave 4.2: 90% Mietkürzung und der Weg zu 200-ms-Slots

Drei feature-gesteuerte Upgrades begannen in der Woche vom 17. August auf dem Solana-Mainnet zu aktivieren. Eine 90-prozentige Reduzierung der On-Chain-Speichermiete, eine 3,3-fache Erhöhung der maximalen Transaktionsgröße und eine schrittweise Reduzierung der Slot-Zeit von 400 ms auf 200 ms stellen die bedeutendste Infrastrukturänderung von Solana dar, seit Firedancer das Mainnet erreicht hat.

Solanas Infrastruktur-Roadmap für 2026 ist eine Abfolge von Wetten, die aufeinander aufbauen. Firedancer erreichte das Mainnet im Dezember 2025 und trägt nun etwa 14 % des Mainnet-Stakes über mehr als 20 % der aktiven Validatoren. Agave 4.2 verändert die wirtschaftlichen und leistungsbezogenen Eigenschaften des Netzwerks, das diese Validatoren betreiben. Alpenglow, das im nächsten Release erscheint, ersetzt den Konsensmechanismus vollständig. Jede Schicht hängt von der vorherigen ab, und jede verändert, was Entwickler auf Solana bauen können.

Dieser Artikel analysiert die drei Agave-4.2-Upgrades, misst, was jedes einzelne in der Praxis verändert, und untersucht, wie sie Solana gegen Ethereums Hegota-Roadmap und den breiteren Wettbewerb um die Aufmerksamkeit von Entwicklern und Nutzern positionieren.

Die Mietreduzierung: Was Konten mit 0,016 $ für Entwickler bedeuten

Miete auf Solana ist das Mindestguthaben, das ein Benutzer einzahlen muss, um ein Konto offen zu halten. Die Einlage skaliert mit der Menge der gespeicherten Daten. Unter dem vorherigen Satz erforderte ein Standard-SPL-Token-Konto etwa 0,16 $ in SOL als mietbefreite Einlage. Dieser Betrag ist keine Gebühr. Er ist für die gesamte Lebensdauer des Kontos gesperrt und wird zurückgegeben, wenn das Konto geschlossen wird.

SIMD-0437 senkt die Lamports-pro-Byte-Konstante um den Faktor 10, von 6.960 auf 696. Die mietbefreite Einlage für dasselbe Token-Konto sinkt auf etwa 0,016 $. Für ein einzelnes Konto ist der Unterschied trivial. Für Anwendungen, die Tausende oder Millionen von Konten erstellen, ist der Unterschied strukturell.

Eine dezentrale Börse, die ein Orderbuch auf der Chain unterhält, erstellt für jede offene Order ein Konto. Ein Gaming-Protokoll, das den Spielerzustand verfolgt, erstellt für jeden aktiven Spieler ein Konto. Eine Tokenisierungsplattform, die Bruchteilsaktien ausgibt, erstellt für jeden Inhaber ein Konto. In jedem Fall skaliert die Kosten für das Bootstrapping der Anwendung linear mit der Anzahl der Konten, und SIMD-0437 reduziert diese Kosten um 90 %.

Der praktische Effekt ist, dass Kategorien von Anwendungen, die auf Solana beim vorherigen Mietsatz unwirtschaftlich waren, beim neuen Satz rentabel werden. On-Chain-Orderbücher mit granularen Preisstufen, vollständig On-Chain-Spiele mit persistentem Zustand für Millionen von Spielern und Tokenisierungsplattformen mit Zehntausenden von Inhabern werden alle erheblich billiger zu betreiben.

Das Gegenargument ist, dass billigerer Speicher die Zustandsaufblähung erhöht. Jedes Konto, das auf Solana existiert, belegt Speicherplatz, den Validatoren speichern und verarbeiten müssen. Die Reduzierung der Kosten für die Erstellung von Konten um 90 % könnte zu einem entsprechenden Anstieg der Anzahl der Konten führen, was die Hardware-Anforderungen der Validatoren belastet. Anza, das Entwicklungsteam hinter Agave, hat argumentiert, dass Zustandskompression und Funktionen zur Kontolebenszyklusverwaltung in zukünftigen Releases die Aufblähung unabhängig vom Mietsatz angehen werden.

Größere Transaktionen: Von Workarounds zur atomaren Ausführung

Das Transaktionslimit von 1.232 Byte ist einer der hartnäckigsten Schmerzpunkte für Entwickler bei Solana. Die Einschränkung ergibt sich aus der UDP-basierten Paketgrößenbegrenzung des Netzwerks, die beim Start festgelegt und nie aktualisiert wurde. Entwickler, die mit komplexen Operationen, ZK-Beweisen, großen Multisig-Konfigurationen und Multi-Instruction-DeFi-Transaktionen arbeiten, mussten die Arbeit auf mehrere Transaktionen aufteilen oder Adress-Lookup-Tabellen verwenden, um Referenzen zu komprimieren.

SIMD-0296 erhöht das Limit auf 4.096 Byte durch ein neues v1-Transaktionsformat. Das Format ersetzt ComputeBudgetProgram-Anweisungen durch eine Konfigurationsmaske, die direkt im Transaktionsheader getragen wird, und schafft so Platz für tatsächliche Anweisungsdaten. v1-Transaktionen werden durch ein führendes Versionsbyte von 129 identifiziert und unterstützen keine Adress-Lookup-Tabellen, aber bei 4.096 Byte kann die vollständige Adressliste in den meisten Fällen direkt aufgenommen werden.

Die Auswirkungen sind vor allem bei drei Kategorien von Entwicklern zu spüren. Die Verifizierung von ZK-Beweisen, die das Übergeben von Beweisdaten als Transaktionseingabe erfordert, kann nun als eine einzige atomare Transaktion erfolgen, anstatt auf mehrere Aufrufe aufgeteilt zu werden. Große Multisig-Wallets mit vielen Unterzeichnern können alle Signaturen in einer Transaktion einschließen. Und On-Chain-Signaturschemata wie BLS, die größeres Schlüsselmaterial erfordern, können ohne Workarounds ausgeführt werden.

Bestehende Anwendungen müssen nicht geändert werden. Die v0- und Legacy-Transaktionsformate funktionieren weiterhin genau wie zuvor. Nur Anwendungen, die die größere Größe benötigen, müssen v1 übernehmen. Indexierer und Block-Explorer, die rohe Transaktionsbytes dekodieren, müssen das neue Layout erkennen, aber der Migrationspfad ist opt-in und nicht erzwungen.

Die 3,3-fache Erhöhung mag im Vergleich zu Ethereums praktisch unbegrenztem Calldata bescheiden erscheinen. Der Unterschied besteht darin, dass Solana-Transaktionen in einem einzigen Slot mit deterministischer Reihenfolge ausgeführt werden, während Ethereum-Transaktionen mit variablen Gaskosten um die Aufnahme in einen Block konkurrieren. Solanas Ansatz tauscht Flexibilität gegen Geschwindigkeit: Eine 4.096-Byte-Transaktion auf Solana bestätigt in unter einer Sekunde, während eine vergleichbare Ethereum-Transaktion je nach Gaspreisen und Blocküberlastung Minuten warten kann.

Der Weg zu 200ms-Slots

SIMD-0525 ist das ehrgeizigste der drei Upgrades und das mit den sichtbarsten Auswirkungen für Benutzer. Die aktuelle Solana-Slot-Zeit beträgt 400ms, was bedeutet, dass etwa alle 0,4 Sekunden ein neuer Block erzeugt wird. SIMD-0525 zielt auf eine Reduzierung auf 200ms ab, was die Blockproduktionsrate des Netzwerks effektiv verdoppelt.

Die Reduzierung erfolgt nicht sofort. Sie erfolgt in vier aufeinanderfolgenden 50ms-Schritten: 400ms auf 350ms, dann 300ms, dann 250ms, dann 200ms. Jede Stufe ist durch eine Feature-Aktivierung abgesichert, die von den Validatoren übernommen werden muss. Das Protokoll enthält eine kritische Sicherheitsvorkehrung: Wenn die Block-Skip-Raten in irgendeiner Phase einen definierten Schwellenwert überschreiten, schreitet das Netzwerk erst dann zur nächsten Stufe fort, wenn die Stabilität wiederhergestellt ist.

Das Testnetz hat bereits 300ms-Slots demonstriert und damit die ersten beiden Stufen validiert. Die verbleibenden Schritte auf 250ms und 200ms hängen von der Leistung der Mainnet-Validatoren unter realer Last ab, die sich von den Testnetz-Bedingungen in Bezug auf Verkehrsvolumen, geografische Verteilung und Hardware-Vielfalt unterscheidet.

Für Benutzer bedeuten schnellere Slots schnellere Bestätigungen. Ein Swap auf einem Solana-DEX bestätigt derzeit in etwa 400ms. Bei 200ms-Slots bestätigt derselbe Swap in der halben Zeit. Für Market Maker bedeuten engere Slots engere Spreads, da das Zeitfenster, in dem ein notierter Preis veralten kann, mit jeder Stufe schrumpft. Für Validatoren bedeuten schnellere Slots höhere Hardware-Anforderungen: Das Rechenbudget pro Slot bleibt gleich, aber die verfügbare Zeit zur Verarbeitung halbiert sich.

Die Sorge um die Validator-Hardware ist nicht theoretisch. ETHNews berichtete, dass das Agave-4.2-Upgrade „die Nutzung billiger, den Betrieb schwerer macht“. Die Senkung der Gebühren senkt die Kosten für Entwickler. Die Verkürzung der Slot-Zeit erhöht die Kosten für Validatoren. Ob der Kompromiss unterm Strich positiv ist, hängt davon ab, ob billigere Entwicklungskosten genügend neue Aktivität anziehen, um die höheren Infrastrukturkosten zu rechtfertigen, die Validatoren tragen müssen.

Firedancers Rolle bei dem Upgrade

Die Leistungsanforderungen von Agave 4.2 wären ohne Firedancers Präsenz auf dem Mainnet schwerer zu erfüllen. Der C- und C++-Validator-Client von Jump Crypto, der im Dezember 2025 das Mainnet erreichte, bietet eine Leistungsbasis, die der ursprüngliche Agave-Client allein nicht garantieren konnte.

Betreiberdaten aus dem Bereitstellungszeitraum 2025 bis 2026 zeigen, dass Firedancer-Validatoren eine Verbesserung der Skip-Rate-Reduzierung um 18 bis 28 Basispunkte erzielten, 15 % weniger verpasste Stimmgutschriften, eine Abstimmungslatenz von etwa 1,002 Slots und vollere Blöcke mit durchschnittlich 47 Millionen gegenüber 44,8 Millionen Recheneinheiten unter Agave. Diese Margen sind wichtig, wenn sich die Slot-Zeiten halbieren, da die Toleranz für Verarbeitungsverzögerungen mit jedem Dekrement schrumpft.

Firedancer trägt jetzt etwa 14 % des Mainnet-Stakes über mehr als 20 % der aktiven Validatoren. Die Client-Vielfalt ist auch ein Resilienzmerkmal: Ein Fehler, der Agave zum Absturz bringt, wirkt sich nicht unbedingt auf Firedancer aus und umgekehrt. Für ein Netzwerk, das sich darauf vorbereitet, seine Slot-Zeit zu halbieren und dann seinen Konsensmechanismus vollständig zu ersetzen, sind zwei unabhängige Clients kein Luxus, sondern eine Sicherheitsanforderung.

Alpenglow: Die Konsens-Neufassung, die im nächsten Release wartet

Agave 4.2 liefert die vollständige Alpenglow-Codebasis, aktiviert sie jedoch nicht auf dem Mainnet. Diese Aktivierung ist Agave 4.3 vorbehalten, das für Oktober 2026 geplant ist. Wenn es erscheint, wird Alpenglow sowohl Proof of History als auch TowerBFT ersetzen, die beiden Systeme, die Solana seit dem Start im Jahr 2020 betreibt.

Der Ersatz ist Votor, ein Abstimmungsalgorithmus, der eine Finalität von etwa 150 ms anstrebt, verglichen mit der aktuellen Finalität von 12,8 Sekunden bei TowerBFT. Votor eliminiert On-Chain-Abstimmungstransaktionen vollständig. Unter TowerBFT übermitteln Validatoren Abstimmungen als reguläre Transaktionen, die Blockspeicherplatz und Recheneinheiten verbrauchen. Unter Votor tauschen Validatoren Abstimmungen direkt über einen separaten Kanal aus, wodurch Blockkapazität für Benutzertransaktionen frei wird.

Das Sicherheitsmodell toleriert gleichzeitig 20 % des Stakes offline und 20 % des Stakes als gegnerisch. Anza hat ein Bug-Bounty-Programm über 50.000 SOL für Alpenglow veröffentlicht, mit Einreichungen ab dem 5. August, was Vertrauen in die Codebasis zeigt, während gleichzeitig anerkannt wird, dass ein Konsensersatz dieser Größenordnung eine externe Sicherheitsüberprüfung erfordert.

Die Reihenfolge ist wichtig. Agave 4.2 reduziert die Miete, erhöht die Transaktionsgröße und beginnt, die Slot-Zeiten zu verkürzen. Agave 4.3 ersetzt den Konsensmechanismus. Jedes Upgrade ist so konzipiert, dass es unabhängig nützlich ist, aber die vollständige Vision – 200-ms-Slots mit 150-ms-Finalität auf einem Konsensprotokoll, das keinen Blockspeicherplatz für Abstimmungen verbraucht – erfordert, dass alle erfolgreich ausgeliefert werden.

Wie dies im Vergleich zu Ethereums Hegota-Roadmap steht

Solana und Ethereum verfolgen unterschiedliche Wege zum gleichen Ziel: niedrigere Kosten, höherer Durchsatz und schnellere Finalität. Der Kontrast zwischen Agave 4.2 und Ethereums Hegota-Upgrade-Plan verdeutlicht die architektonischen Unterschiede.

Ethereums Hegota-Zeitplan sieht eine Präferenzfrist im September vor, wobei das Upgrade selbst für 2027 geplant ist. Der Umfang wird noch definiert: 66 Vorschläge wurden eingereicht, und die Community muss die meisten davon streichen, bevor das Upgrade abgeschlossen wird. Zu den wichtigsten Kandidaten gehören EIP-8182 für native Privatsphäre, FOCIL für Zensurresistenz und Blob-Durchsatzsteigerungen für Rollup-Skalierbarkeit. Das Glamsterdam-Devnet rutschte ab, was den Zeitplan weiter nach hinten verschob.

Solanas Ansatz ist schneller und in seiner Entscheidungsfindung zentralisierter. Anza legt den Zeitplan für die Feature-Aktivierung fest, Validatoren übernehmen ihn, und das Upgrade schreitet voran. Es gibt kein Äquivalent zu Ethereums mehrjährigem EIP-Prozess mit Community-Governance darüber, welche Vorschläge es schaffen. Der Kompromiss ist, dass Solana drei große Upgrades in einem einzigen Release ausliefern kann, während Ethereum 12 bis 18 Monate benötigt, um einen vergleichbaren Umfang an Änderungen abzuschließen.

Die Leistungslücke nach Agave 4.2 ist deutlich. Solana mit 200-ms-Slots und 150-ms-Alpenglow-Finalität würde Transaktionen in unter 400 ms bestätigen. Ethereums aktuelle Finalität beträgt etwa 13 Minuten, und die Verbesserungen durch Hegota, falls sie ausgeliefert werden, zielen auf Single-Slot-Finalität ab, die immer noch in Sekunden statt in Millisekunden gemessen würde.

Die Kostenschere weitet sich ebenfalls aus. Solanas Mietreduzierung macht On-Chain-Speicher um eine Größenordnung billiger. Ethereums L1 bleibt für Speicher teuer, wobei Rollups den Großteil der Kostensenkung durch Blob-Daten absorbieren. Für Entwickler, die entscheiden, wo sie neue Anwendungen bauen, begünstigen die Infrastrukturökonomie zunehmend Solana für Anwendungsfälle, die hohen Durchsatz, niedrige Kosten und schnelle Finalität erfordern.

Das Gegenargument ist, dass Ethereums langsamerer Prozess robustere, kampferprobte Upgrades mit breiterem Community-Konsens hervorbringt. Solanas Geschwindigkeitsvorteil geht zu Lasten des Validator-Zentralisierungsdrucks und einer dünneren Sicherheitsmarge bei großen Infrastrukturübergängen. Der Markt wird letztlich beide Ansätze nach Entwicklerakzeptanz und Nutzeraktivität beurteilen und nicht nur nach technischen Spezifikationen.

Das Signal der Entwicklerabwanderung

Die Infrastruktur-Upgrades sind nur dann von Bedeutung, wenn Entwickler reagieren, indem sie Anwendungen bauen, die sie nutzen. Der führende Indikator ist nicht der SOL-Preis oder TVL, sondern die Rate neuer Programmbereitstellungen und das Volumen der v1-Transaktionsadoption in den Wochen nach der Aktivierung.

Solanas Entwickler-Ökosystem ist im Laufe des Jahres 2026 stetig gewachsen, wobei die Solana Foundation in ihrem jüngsten Ökosystembericht über 2.500 aktive monatliche Entwickler meldet. Es wird erwartet, dass die Mietreduzierung die Entwicklung von On-Chain-Spielen, dezentralen sozialen Protokollen und Tokenisierungsplattformen beschleunigt, die zuvor durch Kontenerstellungskosten eingeschränkt waren.

Auch die Wettbewerbsdynamik ist relevant. Entwickler, die auf günstigere Solana-Infrastruktur gewartet haben, haben sie jetzt. Entwickler, die aus Kostengründen Ethereum-Rollups in Betracht gezogen haben, müssen die zusätzliche Komplexität von L2-Bridging und fragmentierter Liquidität gegen Solanas integriertes L1-Erlebnis zu ähnlichen oder geringeren Kosten abwägen.

Das Gegenargument: Warum diese Upgrades Risiken bergen

Der Bullenfall für Agave 4.2 ist, dass es Solana billiger, schneller und leistungsfähiger macht. Der Bärenfall ist, dass es Solana schwerer zu betreiben macht, den Zentralisierungsdruck auf Validatoren erhöht und gleichzeitig drei gleichzeitige Änderungen an einem Netzwerk einführt, das täglich Milliarden von Dollar an Volumen verarbeitet.

Die Mietreduzierung birgt ein Staatswachstumsrisiko. Wenn die Anzahl der Konten auf Solana proportional zur Kostensenkung zunimmt, müssen Validatoren 10-mal mehr Zustandsdaten speichern und verarbeiten. Die Solana Foundation hat keine Zustandswachstumsprojektion für die Umgebung nach SIMD-0437 veröffentlicht.

Die Slot-Zeit-Reduzierung erhöht die Hardware-Anforderungen zu einem Zeitpunkt, an dem die Validator-Kosten von Solana bereits höher sind als bei den meisten konkurrierenden Netzwerken. Ein Validator, der Solana betreibt, benötigt High-End-Hardware mit schnellem NVMe-Speicher, hoher Netzwerkbandbreite und erheblichem RAM. Die Halbierung der Slot-Zeit verdoppelt nicht die Hardwarekosten, verringert jedoch die Fehlertoleranz und könnte kleinere Validatoren unter die Leistungsschwelle drücken, die erforderlich ist, um Skip-Strafen zu vermeiden.

Die Erhöhung der Transaktionsgröße führt ein neues Format ein, das Indexer, Wallets und SDKs unterstützen müssen. Obwohl die Migration optional ist, schafft die Fragmentierung des Ökosystems zwischen v0-, Legacy- und v1-Transaktionsformaten zusätzliche Komplexität für Entwickler und Infrastrukturanbieter.

Das Timing birgt auch ein Ausführungsrisiko. Die gleichzeitige Aktivierung von drei Hauptfunktionen in einem Netzwerk, das täglich Milliarden von Dollar verarbeitet, bedeutet, dass etwaige Wechselwirkungen zwischen den Upgrades, ein Szenario, das das Testnetz möglicherweise nicht vollständig repliziert, unter Produktionslast auftreten könnten. Die gestaffelte Slot-Zeit-Reduzierung mildert das größte Einzelrisiko, aber die Mietreduzierung und die Erhöhung der Transaktionsgröße werden ohne gleichwertige Sicherheitsvorkehrungen aktiviert.

Es gibt auch ein weniger diskutiertes Wettbewerbsrisiko. Wenn Agave 4.2 erfolgreich ist, bestätigt es die These, dass ein einzelnes Team große Infrastrukturänderungen schneller umsetzen kann als Ethereums dezentraler Governance-Prozess. Diese These zieht kurzfristig Entwickler an. Langfristig schafft sie eine Abhängigkeit von Anzas anhaltender Kompetenz und Ausrichtung auf das Ökosystem. Ethereums langsamerer Prozess verteilt dieses Risiko auf eine breitere Gruppe von Mitwirkenden. Ob Geschwindigkeit oder Widerstandsfähigkeit wichtiger ist, hängt vom Zeithorizont ab.

Was die Bären-These widerlegen würde: die erfolgreiche Aktivierung aller drei Funktionen ohne Anstieg der Überspringungsraten, keine Abwanderung von Validatoren und messbares Wachstum der Entwickleraktivität und der On-Chain-Konten innerhalb von 90 Tagen. Das 90-Tage-Fenster ist wichtig, weil Infrastrukturänderungen ihre Auswirkungen oft allmählich und nicht sofort zeigen.

Was Sie sehen sollten

• Skip-Rate nach jeder Slot-Zeit-Dekrementierung. Die Schutzmaßnahme in SIMD-0525 stoppt den Fortschritt, wenn die Skip-Raten den Schwellenwert überschreiten. Ob das Netzwerk alle vier Dekrementierungen durchläuft oder auf einem Zwischenschritt stoppt, wird die realen Grenzen der Validator-Infrastruktur von Solana aufzeigen.
• Kontoerstellungsrate nach der Mietreduzierung. Ein starker Anstieg neuer Konten bestätigt die These, dass Miete ein bedeutendes Hindernis für die Entwicklung war. Eine flache Kontoerstellung würde darauf hindeuten, dass die Einschränkung woanders lag.
• Adoption von v1-Transaktionen. Wie schnell Wallet-Anbieter, DEXs und DeFi-Protokolle das größere Transaktionsformat übernehmen, wird bestimmen, ob die Größensteigerung zu neuen Fähigkeiten führt oder ungenutzt bleibt.
• Ergebnisse des Alpenglow-Bug-Bounty-Programms. Das 50.000-SOL-Bug-Bounty-Programm, das vor der Agave-4.3-Veröffentlichung endet, wird öffentliche Sicherheitserkenntnisse liefern, die darüber informieren, ob der Konsenswechsel im Oktober planmäßig stattfindet.
• Entwicklung des Firedancer-Stake-Anteils. Client-Vielfalt ist eine Voraussetzung für das Risikoprofil dieser Upgrades. Ob der 14%ige Stake-Anteil von Firedancer auf 33% wächst, den Schwellenwert, der allgemein als notwendig für sinnvolle Widerstandsfähigkeit angesehen wird, ist wichtig für die Netzwerksicherheit während des Übergangs.

Häufig gestellte Fragen