Solanas v1-Transaktionsformat hebt die pro Transaktion zulässige Payload-Obergrenze von 1.232 Bytes auf 4.096 Bytes an, etwa ein Sprung um den Faktor 3,3, und läuft bereits auf Testnet und Devnet (Epoche 1140). Die Mainnet-Aktivierung steht auf Solanas Live-Upgrade-Seite weiterhin aus, mit einem Changelog vom 28. August, der vermerkt, v1-Transaktionen seien „coming soon". Dieses Zeitfenster ist der Vorlauf zu zwei sehr unterschiedlichen Kompatibilitätsfallen für die umgebende Infrastruktur: RPC-Clients, die nicht aktualisiert werden, können beim Auftreffen auf eine v1-Transaktion sofort einfrieren, während Indexer, Relayer und Fee-Sponsoren weiterlaufen und still die falschen Ressourcenlimits melden können.
Warum das wichtig ist
Die Schlagzeilen-Payload-Erhöhung ist das Verkaufsargument des Upgrades, aber die Fehlermodi sitzen in der Verkabelung, die die meisten Nutzer nie sehen. RPC-Clients, die maxSupportedTransactionVersion: 1 nicht übergeben, erhalten bei v1-getTransaction-Anfragen den Fehler -32015, sehen getBlock komplett fehlschlagen, wenn eine v1-Transaktion in einem Block landet, und beobachten, wie blockSubscribe block: null ausgibt und beim ersten betroffenen Slot stehen bleibt. Das leisere Risiko liegt im ComputeBudget-Handling. V1 verschiebt Compute-Unit-Limits, Loaded-Account-Data-Limits und Priority Fees in ein transactionConfig-Objekt, sodass jeder Indexer, der weiterhin ComputeBudget-Instruktionen scannt, ein Null-Budget meldet, ohne einen Fehler auszulösen, und jeder Relayer, der durch das Lesen dieser Instruktionen ein Fee-Cap durchsetzt, wird sehen, wie sie als No-Ops ausgeführt werden und das bindende Cap abstreifen, das er durchzusetzen glaubte. Geyser- und gRPC-Konsumenten stehen vor einer verwandten Versions-Label-Falle, weil das versioned-Flag des Protobuf sowohl für v0 als auch v1 wahr ist, was veraltete Stubs ein leeres Budget weiterreichen lässt.
Marktauswirkung
Solana fasst dies als Application-Control-Failure und nicht als Konsensfehler auf, sodass Gelder nicht automatisch gefährdet sind. Der Explosionsradius deckt allerdings jeden Paymaster, Explorer, jeden Custody-Stack und jedes On-Chain-Programm ab, das ComputeBudget introspiziert, da keine aktuelle Sysvar oder Syscall die v1-Nachrichtenkonfiguration offenlegt.
Häufig gestellte Fragen
-
Was ist Solanas v1-Transaktionsformat?
Es ist ein aktualisiertes Transaktionsformat, das Solanas pro Transaktion zulässige Payload-Obergrenze von 1.232 Bytes auf 4.096 Bytes anhebt, etwa eine Steigerung um den Faktor 3,3. Legacy- und v0-Transaktionen behalten ihre bestehenden Limits und ihr Verhalten, sodass Anwendungen, die bei diesen Formaten bleiben,…
-
Wie wirkt sich der v1-Freeze-Bug auf RPC-Clients aus?
RPC-Clients, die maxSupportedTransactionVersion: 1 nicht übergeben, erhalten bei v1-getTransaction-Anfragen den Fehler -32015, lassen getBlock komplett ausfallen, wenn eine v1-Transaktion in einem Block landet, und beobachten, wie blockSubscribe block: null ausgibt und beim ersten betroffenen Slot einfriert.
-
Warum brechen v1-Fee-Cap-Prüfungen stillschweigend?
V1 verschiebt Compute-Unit-Limits, Loaded-Account-Data-Limits und Priority Fees in ein transactionConfig-Objekt. Relayer und Paymaster, die Fee-Caps durch Scannen von ComputeBudget-Instruktionen durchsetzen, sehen diese Instruktionen in v1 als No-Ops ausgeführt, sodass das Cap nicht mehr bindet, ohne einen Fehler…
-
Sind Nutzergelder durch das Solana-v1-Upgrade gefährdet?
Nein. Die Analyse fasst dies als Application-Control-Failure und nicht als Konsensfehler auf, und Nutzergelder sind nicht automatisch gefährdet. Das Risiko liegt bei Relayern, Explorern, Custody-Stacks und On-Chain-Programmen, die ComputeBudget introspizieren und vor dem Live-Gang von v1 Updates benötigen.
-
Welche Software-Versionen verarbeiten Solana v1 korrekt?
Leserfähige Releases umfassen @solana/kit 8.0.0, @solana/web3.js 3.0.0-rc.3, Rust solana-* 4.2.x, Python solders 0.29.0, solana-go 1.23.0, yellowstone-grpc-proto 12.6.0, geyser-Plugin 15.1.1 und gRPC-Client 12.0.0, je nach Stack.