Solana zielt auf den 9. September für Transaction v1 ab, ein neues Format, das die maximale serialisierte Transaktionsgröße von 1.232 Bytes auf 4.096 Bytes erhöht.
Zusammenfassung
- Solana plant, die maximale Transaktionsgröße am Mittwoch im Mainnet von 1.232 Bytes auf 4.096 Bytes zu erhöhen.
- Transaction v1 bleibt optional, während Legacy- und v0-Formate weiterhin unter den bestehenden Größenlimits funktionieren.
- Anwendungen, die Blöcke lesen, müssen Version eins unterstützen oder riskieren Fehler, wenn sie auf das neue Format stoßen.
- V1 entfernt Address Lookup Tables und speichert Ressourcenlimits direkt in den Konfigurationsmetadaten jeder Transaktion.
- Die offizielle Roadmap von Solana kennzeichnet die Mainnet-Aktivierung als ausstehend, sodass der Zeitplan für den 9. September möglicherweise noch änderbar ist.
Die Erhöhung gibt Entwicklern etwa 3,3-mal mehr Transaktionsraum. Die offizielle Roadmap von Solana besagt, dass die zusätzliche Kapazität Zero-Knowledge-Beweise, große Multisignatur-Operationen, Batches und einige Onchain-Signaturschemata aufnehmen kann.
Große Operationen mussten zuvor in mehrere Transaktionen aufgeteilt werden, wenn ihre Anweisungen, Signaturen und Kontoinformationen die 1.232-Byte-Grenze überschritten. Dieser Prozess erhöhte die Komplexität, da eine Transaktion erfolgreich sein konnte, während ein anderer Schritt fehlschlug.
Transaction v1 könnte es Entwicklern ermöglichen, mehr dieser Anweisungen in einer atomaren Operation zu kombinieren. Entweder sind alle Anweisungen erfolgreich oder die gesamte Transaktion schlägt fehl. Das Modell könnte Handelsrouten, vertrauliche Übertragungen, Cross-Chain-Operationen und Anwendungen, die komplexe kryptografische Beweise verarbeiten, begünstigen.
Das Upgrade erhöht nicht Solanas Limit von 64 referenzierten Konten pro Transaktion. Anwendungen können mehr Daten und Anweisungen enthalten, aber sie können nicht automatisch mit mehr Konten interagieren.
Bestehende Solana-Transaktionen bleiben gültig
Transaction v1 ist optional. Wallets und Anwendungen können weiterhin Legacy- und v0-Transaktionen unter dem bestehenden Limit von 1.232 Bytes senden. Benutzer müssen vor der Aktivierung keine Token migrieren, SOL umtauschen oder einen Anspruch abschließen.
Entwickler müssen das neue Format bewusst übernehmen, um auf seine größere Kapazität zuzugreifen. Die Solana-Dokumentation identifiziert drei unterstützte Formate: Legacy, v0 und v1. Jedes Format organisiert Kontoadressen und Ressourcenlimits unterschiedlich.
Das v0-Format verwendet Address Lookup Tables (ALTs), um Kontoadressen durch komprimierte Ein-Byte-Indizes darzustellen. V1 entfernt ALTs und platziert vollständige 32-Byte-Kontoadressen direkt in der Transaktion.
Dies schafft einen Kompromiss. V1 bietet eine größere Gesamthülle, aber Anwendungen, die stark auf Lookup-Tabellen angewiesen sind, benötigen möglicherweise mehr Bytes, um dieselben Konten darzustellen. Solanas technische Analyse ergab, dass 90 % der Stichprobentransaktionen bei der Konvertierung von v0 zu v1 weniger als 1.400 Bytes hinzufügen würden.
Infrastrukturanbieter müssen ihre Software aktualisieren
Das Hauptkompatibilitätsrisiko betrifft Dienste, die Blöcke und Transaktionen lesen. Remote Procedure Call-Anbieter müssen ihre maximal unterstützte Transaktionsversion auf eins setzen. Andernfalls könnten Anfragen fehlschlagen, wenn sie auf eine v1-Transaktion stoßen.
Indexierer, Explorer und Analysedienste müssen ebenfalls ändern, wie sie Ressourcenlimits abrufen. Legacy- und v0-Transaktionen platzieren Compute-Limits und Prioritätsgebühreneinstellungen in ComputeBudget-Anweisungen. V1 speichert sie in einer dedizierten Transaktionskonfiguration.
Veraltete Dienste könnten daher falsche Informationen anzeigen. Beispielsweise könnte ein Explorer eine Null-Prioritätsgebühr anzeigen, obwohl der Benutzer eine bezahlt hat. Gebührensponsoren und Anwendungen, die Transaktionslimits prüfen, müssen die neue Konfiguration lesen, anstatt alte Anweisungen zu scannen.
Anwendungen, die v1-Transaktionen senden, müssen explizit Compute-Unit- und geladene Datenlimits festlegen, da beide standardmäßig null sind. Entwickler sollten die Transaktionskonstruktion, -signierung und -decodierung testen, bevor sie Produktionsverkehr auf das Format umstellen.
Der 9. September bleibt ein angestrebtes Aktivierungsdatum
Jacob Creech, Vizepräsident für Technologie der Solana Foundation, nannte den 9. September als geplantes Mainnet-Datum. Wie crypto.news zuvor berichtete, ist das Upgrade in Anzas Agave 4.2-Rollout enthalten.
Allerdings kennzeichnet die offizielle Roadmap das Mainnet-Feature weiterhin als "nicht aktiviert". Sie besagt auch, dass der Veröffentlichungszeitplan von Anza "vorläufig und änderbar" ist. Laut der neuesten Statusseite der Foundation haben Testnetz und Devnetz das Feature bereits aktiviert.
Die Größensteigerung stammt von SIMD-0296, während SIMD-0385 das v1-Format definiert. Jacob Creech und Andrew Fitzgerald sind Co-Autoren beider Vorschläge.
Die Obergrenze von 4.096 Byte wurde teilweise gewählt, weil vier Kilobyte einer üblichen Speicherseitengröße entsprechen, die von Validator-Hardware verwendet wird. Größere Transaktionen werden auch zusätzliche Bandbreite verbrauchen, obwohl das Upgrade keine separate Gebühr pro Byte einführt.
Transaktion v1 bleibt getrennt von Solanas Mietkürzungen, kürzeren Slot-Zielen und dem Alpenglow-Konsens-Redesign. In verwandter Berichterstattung meldete crypto.news, dass Alpenglow eine Finalität von etwa 150 Millisekunden anstrebt, wobei Oktober ein Entwicklungsziel bleibt und kein garantiertes Aktivierungsdatum ist.
