Solana V1-Transaktionen erreichen das Testnetz, um mehrstufige Vorgänge in einen einzigen Schritt zu bündeln

Am 1. September startete Anza Transaktionen der Version 1 im Testnetz von Solana, was eine letzte Generalprobe dieses Upgrades vor dem Launch am 9. September ermöglichte.

Die Änderung soll kryptografische und DeFi-Workloads ermöglichen, die zuvor auf verschiedene Transaktionen verteilt werden mussten, nun in einer einzigen atomaren Transaktion zu verarbeiten, wie von Solana Compass angegeben.

Jobs, die zuvor aufgeteilt waren, passen nun in einen einzigen Aufruf.

Die auffälligste Änderung ist die erhöhte Speicherkapazität: Die maximale Größe einer serialisierten Solana-Transaktion wurde von 1.232 Bytes auf 4.096 Bytes erhöht – das entspricht einem Anstieg um das 3,3-Fache und trat ab der Testnet-Epoche 1025 in Kraft.

Laut der Webseite zur großen Transaktionsaktualisierung der Solana Foundation wird eine solche große Transaktionsgröße es ermöglichen, Zero-Knowledge-Beweise, große Multisig-Transaktionen sowie verschiedene Signaturschemata zu implementieren, die innerhalb einer einzelnen Transaktion bisher nicht möglich waren.

Dadurch müssen weniger Transaktionen verarbeitet werden, es werden weniger Mittel für Signaturen benötigt, und es entfällt die Wartezeit auf eine Kette von Bestätigungen. BLS-Signaturschemata sowie vertrauliche Transaktionen und Multisig-Konfigurationen profitieren von diesem Upgrade.

Es gibt zwei wesentliche Vorschläge für diese Verbesserung: SIMD-0296 erhöht die Transaktionsgröße von 1.232 Bytes auf 4.096 Bytes, während SIMD-0385 das V1-Nachrichtenformat definiert und die Transaktionskonfiguration direkt in die Nachricht verschiebt.

Weniger als einen Tag nach Aktivierung des Upgrades veröffentlichte Anza-CEO Brennan Watt einen Beitrag auf X, in dem er eine große Transaktion im Testnet-Explorer erwähnte, mit der Meldung: „ACHTUNG: Große Transaktionen sind im Testnetz eingetroffen.“

Warum eine einzelne Transaktion einem Bundle überlegen ist

Die Bedeutung der Atomarität ergibt sich daraus, dass Entwickler manchmal Solanas alte Größenbeschränkung umgangen haben, indem sie Jito-Bundles nutzten. Tatsächlich erklärt SIMD-0296 dieses Workaround und weist darauf hin, dass Bundles auf Protokollebene keine Atomarität bieten, ähnlich wie bei einer nativen Transaktion.

Laut Jitos Dokumentation können Bundles bis zu fünf Transaktionen enthalten, die sequenziell nach dem Alles-oder-Nichts-Prinzip verarbeitet werden. Bundles operieren jedoch innerhalb von Jitos Block-Engine und konkurrieren um Validatoren-Tipps. V1-Transaktionen hingegen bezeichnen eine einzelne native Solana-Transaktion, die die atomare Garantie auf Transaktionsebene von Solana mit sich bringt.

Für DeFi-Entwickler kann dies helfen, Swap-Routen, Beweise und andere Arten von mehrstufigen Transaktionen einfacher zu implementieren. Wenn die Operation vollständig durch eine V1-Transaktion abgedeckt ist, gelingt sie entweder oder wird als einzelne native Transaktion zurückgegeben, anstatt sich auf ein Bundle von Transaktionen zu verlassen.

Was DeFi über zusätzliche Bytes hinaus gewinnt

V1 ändert auch die Transaktionsstruktur. Während Legacy und V0 Prioritätsgebühren und Ressourcenanfragen über ComputeBudget-Anweisungen verarbeiten, übernimmt SIMD-0385 diese Konfigurationen in die V1-Transaktionskonfigurationen und vereinfacht so die Aufgabe der Validatoren bei der Identifizierung von Ressourcenbedarfen, ohne aktiv durch die Anweisungsliste suchen zu müssen.

V1 eliminiert zudem Address Lookup Tables (ALTs), die von V0 zur Verkürzung von Kontoadressen genutzt wurden. Laut der Analyse des ALT-Tradeoffs bei V1 durch die Foundation erfolgt bei V1 stattdessen die Adressplatzierung inline. Dies macht die Eingabe für Validatoren einfacher im Vergleich zur Methode in rechenintensiven Anwendungen mit vielen Konten in V0, die beim Konvertieren mehr Bytes verbrauchen.

Der praktische Nutzen für Router und DEX-Aggregatoren besteht darin, dass nun mehr Spielraum für komplexe atomare Transaktionen besteht. Diese Verbesserung ist jedoch nicht ohne Einschränkungen möglich. Tatsächlich bleibt Solanas maximale Kapazität von 64 verschiedenen Accounts unverändert, sodass Anwendungen, die stark auf Accounts angewiesen sind, weiterhin unter dieser Beschränkung leiden können, auch wenn das Byte-Limit keine Rolle mehr spielt.

Das Upgrade wird eingeführt, während Solana einen Sprung in den On-Chain-Finanzbereich vollzieht. Der von Galaxy bereitete Bericht über Solana für das zweite Quartal 2026 zeigt steigende Aktivitäten bei Stablecoins, tokenisierten Aktien und realweltlichen Vermögenswerten.

Laut Galaxy wird das Potenzial von Solana in Zukunft maßgeblich davon abhängen, wie gut sich Assets für Kreditvergabe, Besicherung, Margin und Erträge nutzen lassen – und nicht nur für Emission oder Handel. Basierend auf DeFiLlama-Daten zu Solana scheint die Plattform eine starke DeFi-Präsenz zu haben.

Darüber hinaus fällt der Zeitpunkt des Upgrades mit der Agave 4.2-Upgrade-Phase zusammen. Informatorisch stellte Cryptopolitan fest, dass die geplante schrittweise Einführung von Kostensenkungen voraussichtlich Einsparungen von rund 90 % sowie eine Reduzierung der Verarbeitungszeit von 500 auf 200 Millisekunden bewirken wird – ein Vorteil für Stablecoin-Emitter, Wallet-Anbieter und Zahlungssysteme.

RPC-Betreiber haben eine Woche Zeit zur Aktualisierung

V1 ist opt-in, daher funktionieren Legacy- und V0-Transaktionen weiterhin. Die Frage ist, ob die Infrastruktur, die V1-Traffic verarbeitet, bereit ist.

Anza hat RPC-Anbieter verpflichtet, auf Agave v4.2.2 oder v4.3.0-beta.3 umzusteigen. Die Helius Agave 4.2-Migrationscheckliste betont zudem, dass RPC-Konsumenten, die keine V1-Konformität angeben, bei Verwendung einer V1-Transaktion Aufruffehler wie getBlock erfahren können.

Der Prozess begann mit lokalen Tests von V1 am 24. August, kurz darauf wurde am 29. August das Mainnet-Datum bestätigt. V1 wurde am 1. September im Testnetz bei Epoch 1025 aktiviert, mit einer geplanten Aktivierung im Mainnet am 9. September.

Dieser letzte Testlauf dient als abschließender Vorbereitungsschritt für RPC-Anbieter, Indexer, Wallets, SDKs und analytische Plattformen vor dem Mainnet-Launch.