Der Vizepräsident für Technologie der Solana Foundation, Jacob Creech, skizzierte am 30. August mehrere bevorstehende Solana-Upgrades. Transaction V1 ist für den 9. September geplant, während die erste Stufe einer Netzwerk-Mietreduzierung in der Woche ab dem 31. August erwartet wird.
Zusammenfassung
- Solana plant, Transaction V1 am 9. September zu aktivieren und die Transaktionsgröße auf 4.096 Bytes zu erhöhen.
- Die erste Mietreduzierungsstufe beginnt nächste Woche und startet einen fünfstufigen Weg zu 90% Einsparungen.
- Solana hat die Ziel-Slot-Zeit bereits auf 350 Millisekunden gesenkt, mit 300, 250 und 200 später geplant.
- Alpenglow bleibt für Oktober geplant, wobei Solana nach der Mainnet-Aktivierung eine Finalität von etwa 150 Millisekunden anstrebt.
- Legacy- und Version-Null-Transaktionen bleiben kompatibel, da Entwickler sich für das größere V1-Format entscheiden müssen.
Creech sagte auch, dass Entwickler planen, die Slot-Zeiten weiter zu verkürzen und Alpenglow für Oktober anzuvisieren. Diese Änderungen folgen jedoch separaten Aktivierungsprozessen. Transaction V1 wird die Slot-Zeiten nicht automatisch reduzieren oder Alpenglow aktivieren.
Transaction V1 erhöht Solanas Limit auf 4.096 Bytes
Transaction V1 wird Solanas maximale serialisierte Transaktionsgröße von 1.232 Bytes auf 4.096 Bytes erhöhen. Die Erhöhung beträgt etwa das 3,3-fache des bestehenden Limits, laut Solanas offizieller Upgrade-Roadmap.
Das größere Format könnte Transaktionen mit Zero-Knowledge-Beweisen, komplexen Multisignatur-Anweisungen und anderen datenintensiven Operationen unterstützen. Der zugehörige SIMD-0296-Vorschlag identifiziert auch BLS-Signaturen und Cross-Chain-Operationen als mögliche Verwendungen.
Entwickler müssen sich für das V1-Format entscheiden. Bestehende Legacy- und Version-Null-Transaktionen bleiben gültig. Transaction V1 unterstützt keine Adressnachschlagetabellen, was bedeutet, dass Anwendungen entscheiden müssen, welches Format für jede Transaktion geeignet ist.
Die Änderung erfordert auch, dass Wallets, Anwendungsprogrammierschnittstellen und andere Infrastruktur größere Datenmengen verarbeiten. Der Vorschlag erkennt mögliche Bandbreiten- und Netzwerkfragmentierungsrisiken an, was koordinierte Tests vor einer breiteren Einführung wichtig macht.
Solana-Mietreduzierung beginnt mit einem von fünf Schritten
Die erste Mietreduzierung liefert nicht sofort das volle 90%-Ziel. Solana plant fünf Stufen, die schließlich die Mietberechnung von 6.960 Lamports pro Byte auf 696 Lamports pro Byte senken würden.
Solana verwendet mietbefreite Guthaben, um unkontrolliertes Zustandswachstum zu begrenzen. Anwendungen sperren SOL, wenn sie Konten erstellen, die Daten speichern. Dieses SOL ist im Allgemeinen wiederherstellbar, wenn das Konto geschlossen wird, was bedeutet, dass die Miete eher wie eine erstattungsfähige Kaution als eine wiederkehrende Netzwerkgebühr funktioniert.
Niedrigere Anforderungen würden die Menge an SOL reduzieren, die Entwickler sperren müssen, wenn sie Token-Konten, Programm-Konten und andere Onchain-Zustände erstellen. Dies könnte die Einstiegskosten für Anwendungen senken, die viele Benutzerkonten verwalten.
Agave 4.2 enthielt den notwendigen Code, aber Solana platzierte die Änderungen hinter unabhängigen Feature-Gates. Wie crypto.news bereits berichtete, können Validatoren die Miet-, Transaktionsgrößen- und Slot-Zeit-Upgrades nach dem Testen separat aktivieren.
Schnellere Solana-Slots folgen einem separaten Zeitplan
Solana hat seine Ziel-Slot-Zeit bereits auf 350 Millisekunden reduziert, gegenüber dem vorherigen Ziel von 400 Millisekunden. Das Netzwerk plant weitere Stufen bei 300, 250 und schließlich 200 Millisekunden.
Creech nannte keine Daten für diese verbleibenden Phasen. Jede Reduzierung erfordert eine separate Funktionsaktivierung. Netzwerkentwickler können daher die Validator-Leistung überwachen, bevor sie zum nächsten Ziel übergehen.
Kürzere Slots können die Transaktionsbestätigungsgeschwindigkeit verbessern und die Häufigkeit erhöhen, mit der Validatoren Blöcke produzieren. Sie stellen jedoch auch höhere Anforderungen an Timing und Netzwerk für die Validatoren. Solana plant, die Ressourcengrenzen während der Einführung proportional anzupassen.
Transaction V1 und reduzierte Slot-Zeiten stehen im Zusammenhang mit Solanas breiterer Leistungs-Roadmap, bleiben aber technisch getrennt. Berichte, die den 9. September als Datum für beide Änderungen nennen, würden Creechs Ankündigung übertreiben.
Alpenglow bleibt ein Ziel für Oktober
Alpenglow ist Solanas vorgeschlagenes Konsens-Redesign. Solana sagt, dass es darauf abzielt, die Transaktionsfinalität auf etwa 150 Millisekunden zu reduzieren, verglichen mit dem längeren Bestätigungsprozess des aktuellen Konsenssystems.
Die offizielle Roadmap listet Alpenglow als "in Entwicklung", während Agave 4.3 für Oktober erwartet wird. Creechs Beitrag unterstützt Oktober als aktuelles Ziel, aber keine der Aussagen bestätigt ein garantiertes Mainnet-Aktivierungsdatum.
Zuvor wird Solana voraussichtlich die erste Phase der Mietreduzierung beginnen und Transaction V1 am 9. September aktivieren. Weitere Slot-Reduzierungen hängen von separaten Validator-Aktivierungen ab. Alpenglow muss auch Tests abschließen und die erforderliche Netzwerkunterstützung sichern.
Zum Zeitpunkt der Veröffentlichung wurde keine verifizierte Marktbewegung direkt auf Creechs Ankündigung zurückgeführt.
