Solana erweitert Handelslimit auf 4096 Byte

Solana (SOL) bereitet ein Upgrade des Handelsformats v1 vor, das die maximale Größe einer einzelnen Transaktion von 1.232 Byte auf 4.096 Byte erhöht. Dies ist eine technische Änderung, die es ermöglicht, Transaktionen, die etwa 3,3-mal größer sind als das vorherige Limit, auf einmal zu verarbeiten.

Die Solana-Stiftung hat in ihrem offiziellen Upgrade-Dokument die "Größeren Transaktionsgrößen" als "Ausstehende Funktionsaktivierung" klassifiziert. Diese Änderung basiert auf SIMD-0296 und SIMD-0385, und das offizielle Upgrade-Dashboard zeigt Agave 4.2 als die Version, die im August 2026 veröffentlicht werden soll, während die Funktion zur Erweiterung der Transaktionsgröße in einem Aktivierungsstatus bleibt.

Der Kern dieses Upgrades ist das Handelslimit. Das bestehende Handelsgrößenlimit von Solana betrug 1.232 Byte, und das SIMD-0296-Dokument erklärt, dass dieses Limit aus dem Design des IPv6 MTU von 1.280 Byte resultiert. Abzüglich von Headern blieb eine Struktur von 1.232 Byte für die tatsächliche Transaktionslast übrig.

Solana berichtet, dass mit der Einführung von QUIC eine Umgebung geschaffen wurde, die es ermöglicht, größere Transaktionen zu senden, und schlägt ein neues Limit von 4.096 Byte vor. Mit der Änderung der Netzwerkübertragungsstruktur wird das Handelslimit, das zuvor an die Paketgrößenbeschränkungen angepasst war, neu justiert.

Das v1-Format ersetzt nicht das bestehende v0 und die Legacy-Transaktionen. Anwendungen, Wallets und Indexer, die größere Transaktionsgrößen verwenden möchten, müssen auf das neue Format reagieren. Das Solana RPC-Dokument besagt, dass für den Empfang von v1-Nachrichten die Anfrage mit maxSupportedTransactionVersion: 1 konfiguriert werden muss.

In der RPC-Dokumentation enthält die v1-Nachricht ein transactionConfig-Objekt, das Berechnungsgrenzen und Datenbeschränkungen sowie die Prioritätsgebühr umfasst. transactionConfig enthält computeUnitLimit, loadedAccountsDataSizeLimit und priorityFee. Dies unterscheidet sich von der bisherigen Methode, bei der Ressourcenanforderungen als separate Anweisung eingegeben wurden.

Die technische Struktur wird ebenfalls geändert. SIMD-0385 beschreibt, dass v1-Transaktionen das Versionsbyte 129 verwenden und Ressourcenanforderungen im Transaktionsheader anstelle der bisherigen ComputeBudgetProgram-Anweisung enthalten. Die Adress-Lookup-Tabelle (ALT) wird nicht unterstützt.

Die Adress-Lookup-Tabelle reduziert den Platzbedarf, indem sie nicht alle Adressen direkt in die Transaktion einfügt, sondern auf eine externe Tabelle verweist. v1 geht davon aus, dass es häufig möglich ist, Adresslisten direkt innerhalb des Limits von 4.096 Byte aufzunehmen. Allerdings könnte die Wirkung der Limitierung in Workloads, die stark von ALT abhängen, begrenzt sein.

Diese Änderung erweitert den Spielraum für atomare Einzeltransaktionen für Entwickler. Die Solana-Stiftung erklärte, dass Zero-Knowledge-Proofs, große Multisig-Transaktionen, Batch-Operationen und einige On-Chain-Signaturstrukturen mit dem bisherigen Limit von 1.232 Byte schwer in einer Transaktion unterzubringen waren. Atomare Transaktionen sind so strukturiert, dass mehrere Aufgaben entweder gemeinsam erfolgreich oder gemeinsam fehlschlagen.

In komplexen DeFi-Operationen oder institutionellen Multisig-Verfahren kann die Notwendigkeit, Transaktionen mehrfach aufzuteilen, verringert werden. Solana betont, dass die Netzwerkverarbeitungskennzahlen in Bezug auf die Infrastrukturänderungen separat betrachtet werden müssen, auch wenn die wöchentlichen Transaktionssteigerungen mit Gebühreneinnahmen, Entwickleraktivitäten und Token-Nachfrage in Beziehung stehen.

Allerdings beseitigt v1 nicht alle Engpässe. Die offizielle Erklärung von Solana besagt, dass v1 eine Struktur bietet, die es Validatoren und Client-Teams ermöglicht, Gebühren- und Ressourcenanforderungen früher zu lesen. Auf der anderen Seite könnte die Begrenzung auf 64 Konten weiterhin eine Einschränkung für Anwendungsentwickler darstellen.

In den Entwicklerdiskussionen gab es sowohl Erwartungen als auch Bedenken. In einer GitHub-Diskussion wurde die Meinung geäußert, dass größere Transaktionsgrößen für komplexe Swaps, One-Click-DeFi und atomare Liquidationen nützlich sind. Andererseits wurde darauf hingewiesen, dass Netzwerkleistung, Paketaufteilung, Validator-Bandbreite und Gebührenstruktur wichtiger sind.

In der lokalen Validierungsumgebung sind bereits Testmöglichkeiten vorhanden. Das Solana-Beispiel-Repository weist darauf hin, dass die Funktion enable_tx_v1 im solana-test-validator bereits aktiviert ist. Wenn jedoch der Funktionsgate im Laufzeitcode deaktiviert ist, wird die v1-Transaktion als UnsupportedVersion abgelehnt, sodass die Aktivierung je Cluster überprüft werden muss.

Crypto Briefing berichtete, dass v1-Transaktionen in den kommenden Wochen in das Testnetz aufgenommen werden könnten. Der Status in den offiziellen Solana-Dokumenten ist jedoch noch im Aktivierungsstatus. Die Anwendung im Mainnet und der Zeitplan müssen im Rahmen des offiziellen Aktivierungsstatus überprüft werden.

Dieses Upgrade ist eher eine Angelegenheit der Veränderungen in der Entwicklungsinfrastruktur als eine Preisprognose. Wallets, RPCs, Indexer und Entwicklungstools müssen die Unterstützung für die v1-Transaktionsanalyse und transactionConfig überprüfen. Das bestehende v0 und Legacy-Transaktionen funktionieren weiterhin, aber Dienste, die 4.096 Byte-Transaktionen verwenden möchten, müssen die Unterstützung für das neue Format gewährleisten.

Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.