Solana v1 Transaktionen stehen vor der Umstellung auf 4096 Byte und Kompatibilitätsprüfung

Die neue Transaktionsformat v1 von Solana (SOL) steht vor der Aktivierung des Mainnets und wird auf die Kompatibilität der Infrastruktur überprüft. Die maximale Größe einer einzelnen Transaktion wird von 1.232 Byte auf 4.096 Byte erhöht, jedoch liegt der Schwerpunkt darauf, ob RPC, Indexer, gRPC und Gebühren-Sponsoren das neue Format korrekt lesen können, anstatt auf Konsensprobleme der Kette zu achten.

Die Solana Foundation hat auf der Seite für Netzwerk-Upgrades bekannt gegeben, dass Agave 4.2 im Mainnet aktiv ist, jedoch die Funktion "Larger Transaction Sizes" zum Stand 4. September 2026 noch auf Aktivierung wartet. Diese Funktion soll die bestehenden Transaktionslimits um etwa das 3,3-fache erhöhen.

Diese Änderung ist nicht nur eine einfache Größenvergrößerung. SIMD-0296 und SIMD-0385 wurden im Zusammenhang mit großen Multisig, Zero-Knowledge-Proofs (ZK-Proofs) und Batch-Transfers vorgestellt. In v1 wird die Abhängigkeit von der Adressabfragetabelle, die in bestehenden Transaktionen verwendet wird, verringert und die Informationen zu Gebühren und Ressourcenbeschränkungen werden in den separaten Einstellwert transactionConfig verschoben.

Die Art und Weise, wie das bestehende System liest, könnte an dieser Stelle problematisch sein. Wenn Indexer und Gebühren-Sponsoren nur die ComputeBudget-Anweisung überfliegen, um die Gebühren oder die Berechnungseinheiten zu berechnen, könnten sie die Gebührenobergrenze der v1-Transaktionen übersehen oder als 0 lesen. Das Beispiel-Repository der Solana Foundation erklärt, dass die v1-Nachricht anstelle der ComputeBudget-Anweisung die TransactionConfig enthält.

Die Solana RPC-Dokumentation weist darauf hin, dass bei den Aufrufen getTransaction, getBlock und blockSubscribe der Wert maxSupportedTransactionVersion: 1 angegeben werden muss. Wenn dieser Wert weggelassen oder auf 0 gesetzt wird, kann getTransaction einen Fehler ausgeben, wenn eine v1-Transaktion eingeht, und getBlock kann beim Lesen des gesamten Blocks fehlschlagen.

WebSocket-Abonnements sind ebenfalls nicht ausgenommen. Wenn die Einstellungen nicht korrekt sind, kann blockSubscribe block: null ausgeben. Die Solana-Entwicklungsdokumentation empfiehlt, dies nicht als leeren Block, sondern als Fehler zu behandeln. v1-Transaktionen werden durch das erste Byte 129, also 0x81, identifiziert.

In den gRPC- und Geyser-Pfaden können ruhigere Fehler auftreten. Die Solana-Entwicklungsdokumentation warnt, dass gRPC keinen opt-in Wert wie maxSupportedTransactionVersion hat und ältere Protobuf-Stubs das Message.config-Feld verwerfen können. In diesem Fall stoppt das System nicht, aber v1-Transaktionen könnten wie v0 behandelt werden, wodurch die Gebühreneinstellungen übersehen werden könnten.

Das Beispiel-Repository der Solana Foundation schlägt @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0 und yellowstone-grpc geyser 15.1.1 als Mindestversionen vor. Es werden auch separate Beispiele für Lesen, Senden, Blockindizierung und gRPC bereitgestellt.

Die Validierung auf der Seite der Kernwerkzeuge wird ebenfalls fortgesetzt. Das Issue #831 des solana-sdk von anza-xyz hat ein Problem angesprochen, bei dem die maximale Größe von 4.096 Byte in Deserialisierern und Sanitizern nicht korrekt durchgesetzt wird. Die Solana-Statusseite zeigt jedoch, dass zum Stand 4. September 2026 die Mainnet Beta RPC Nodes in Betrieb sind und keine Vorfälle gemeldet wurden.

Diese Angelegenheit hat stark den Charakter einer Kompatibilitätsprüfung der Infrastruktur im Zusammenhang mit der Erhöhung des Transaktionslimits von Solana v1. Während die vorherigen Probleme die 4.096-Byte-Grenze und die Aktivierung von Funktionen pro Cluster betrafen, ist diesmal der Schlüssel, ob das Backend-System die neue Struktur lesen kann, wenn tatsächlich v1-Transaktionen eingehen.

Die Solana-Upgrade-Seite zeigt an, dass die Funktion "Larger Transaction Sizes" zum Stand 4. September 2026 auf Aktivierung wartet. Dieser Zeitrahmen ist eher ein technischer Fahrplan, den Wallets, RPCs, Indexer und Entwicklungstools nacheinander vorbereiten müssen, als ein einzelnes Ereignis, das die Solana-Verarbeitungsstruktur auf einmal ändert.

Technisch gesehen ersetzt die v1-Transaktion nicht die bestehenden v0- und Legacy-Transaktionen. Das bestehende Format funktioniert weiterhin, aber Anwendungen, die größere Transaktionsgrößen und transactionConfig verwenden, setzen die Unterstützung des neuen Formats voraus. Bei Upgrades der Blockchain-Infrastruktur beeinflussen nicht nur die Konsensregeln, sondern auch die Kompatibilität der umgebenden Systeme, die Daten lesen und speichern, das tatsächliche Betriebsrisiko.

Besonders Gebühren-Sponsoren und Indexer könnten stark betroffen sein. Wenn die Gebührenobergrenze oder die Berechnungseinheiten falsch gelesen werden, könnte ein Dienst, der die Kosten anstelle der Nutzer trägt, einer unerwarteten Kostenstruktur ausgesetzt sein, und das Transaktionsanalysetool könnte die Ressourceneinstellungen der v1-Transaktionen falsch aufzeichnen. Dies ist zwar nicht dasselbe wie ein Ausfall der Kette, erfordert jedoch zusätzliche Prüfungen durch die Dienstanbieter.

Inländische Börsen oder Wallet-Anbieter, die Solana-Ein- und Auszahlungen sowie On-Chain-Überwachungen betreiben, sind ebenfalls nicht von denselben Problemen befreit. Sie müssen sicherstellen, dass die Abfrage von Blöcken und Transaktionen, die Indizierung, die Risikobeobachtung und die Gebührenberechnung den v1-Nachrichtenstruktur verarbeiten können. Insbesondere wenn externe Node-Anbieter oder Geyser-basierte Daten verwendet werden, sind die Überprüfung der Protobuf-Reproduzierbarkeit und der Bibliotheksversion erforderlich.

Bis die v1-Transaktionen tatsächlich eingehen, sind die wichtigsten Prüfposten: △Einstellung von maxSupportedTransactionVersion: 1 in den RPC-Aufrufoptionen △Reflexion des Speicherpfads von transactionConfig △Neuerstellung des gRPC-Protobuf-Stubs △Erkennung des 0x81-Version-Präfixes. Laut der Solana-Upgrade-Seite ist "Larger Transaction Sizes" zum Stand 4. September 2026 auf Aktivierung wartend.