Solana hat sein txv1-Feature am 15. September gegen 01:00 UTC zum Beginn der Epoche 1035 auf dem Mainnet aktiviert. Durch das Upgrade steigt die maximale Transaktionsgröße von 1.232 Bytes auf 4.096 Bytes, wodurch mehr als das Dreifache der bisherigen Kapazität zur Verfügung steht.

Der zusätzliche Platz steht über das V1-Transaktionsformat zur Verfügung. Anwendungen müssen die Unterstützung dafür ausdrücklich hinzufügen, bevor sie es verwenden können. Legacy- und V0-Transaktionen bleiben innerhalb ihrer bisherigen Grenzen vollständig unterstützt.

Eine größere Transaktion ist keine größere SOL-Überweisung

Die neue Grenze betrifft die Menge an Informationen, die eine Transaktion enthält, nicht die Menge an SOL, die ein Nutzer senden kann. Eine gewöhnliche Überweisung benötigt in der Regel nur wenige Daten, da sie lediglich eine kleine Zahl von Konten, Anweisungen und Signaturen umfasst.

Komplexere Vorgänge können mehrere Anweisungen, zahlreiche Konto-Adressen, mehrere Genehmigungen oder kryptografische Beweise erfordern. Wenn diese Informationen die frühere Grenze überschritten, mussten Entwickler die Datenmenge reduzieren, den Vorgang auf mehrere Transaktionen aufteilen oder Alternativen wie Address Lookup Tables und Transaktionspakete nutzen.

Solana kann voneinander unabhängige Transaktionen parallel verarbeiten, wie in diesem Leitfaden zur Funktionsweise von Solana beschrieben. V1 verändert dieses Ausführungsmodell nicht. Stattdessen bietet es zusätzlichen Platz, wenn ein einzelner Vorgang mehrere miteinander verbundene Komponenten enthalten muss.

Wenn diese Anweisungen als eine atomare Transaktion eingereicht werden, werden sie als Einheit verarbeitet. Der vollständige Vorgang ist entweder erfolgreich oder seine Änderungen werden rückgängig gemacht. So wird verhindert, dass nur einige Anweisungen das Ledger erreichen.

Vorgänge, die vom zusätzlichen Platz profitieren können

• Gebündelte Trades: Eine Handelsanwendung kann verbundene Anweisungen in einer Transaktion platzieren, anstatt mehrere Bestätigungen zu koordinieren.
• Umfangreiche Multisig-Genehmigungen: Treasury- und Unternehmens-Wallets können mehr Signaturen und Kontoinformationen aufnehmen, wenn mehrere Personen einen Vorgang autorisieren müssen.
• Zero-Knowledge-Proofs: Anwendungen können nachweisen, dass eine Bedingung erfüllt ist, ohne alle zugrunde liegenden Informationen offenzulegen. Der Beweis selbst kann jedoch erheblichen Transaktionsplatz erfordern.
• On-Chain-Signaturschemata: Einige kryptografische Signaturformate erzeugten zuvor mehr Daten, als eine einzelne Solana-Transaktion enthalten konnte.

Die Solana Foundation nennt vertrauliche Überweisungen, verschachtelte Multisigs, gebündelte Vorgänge und bestimmte On-Chain-Signaturschemata als mögliche Einsatzbereiche für das neue Format.

Die meisten Wallet-Nutzer müssen nichts unternehmen

Die Aktivierung erfordert nicht, dass Nutzer ihre SOL übertragen, eine weitere Adresse erstellen oder ein bestehendes Konto umwandeln. Anwendungen, die weiterhin Legacy- oder V0-Transaktionen verwenden, sollten wie vor dem Upgrade funktionieren.

Nutzer benötigen ein kompatibles Wallet, wenn eine Anwendung eine V1-Transaktion senden möchte. Aktualisierte Wallet-Software wird diese Unterstützung verfügbar machen, sobald Anbieter sie einführen. Eine Anwendung sollte dennoch die Kompatibilität prüfen, bevor sie ein Wallet zur Signatur auffordert.

Für Nutzer könnte sich die Änderung letztlich durch weniger Genehmigungsanfragen bei komplexen Vorgängen bemerkbar machen. Ein Dienst, der zuvor mehrere verbundene Transaktionen benötigte, könnte stattdessen eine Anfrage anzeigen und auf eine Bestätigung warten.

Entwickler und Indexer müssen ihre Software aktualisieren

Das Senden von V1-Transaktionen ist optional, doch das Auslesen solcher Transaktionen kann bei nicht aktualisierter Infrastruktur Kompatibilitätsprobleme verursachen.

RPC-Dienste, die Transaktionen oder Blöcke abrufen, müssen maxSupportedTransactionVersion: 1 setzen. Ohne diese Einstellung kann eine Anfrage nach einer V1-Transaktion einen Fehler zurückgeben. Eine einzige nicht unterstützte Transaktion kann außerdem dazu führen, dass eine Anfrage für einen gesamten Block fehlschlägt.

Indexer sind einem anderen Risiko ausgesetzt. V1 speichert sein Compute-Limit, das Limit für geladene Kontodaten und die Prioritätsgebühr innerhalb von transactionConfig statt in Compute-Budget-Anweisungen. Software, die weiterhin den alten Speicherort durchsucht, könnte die Transaktion falsch klassifizieren oder ihre Ressourcenlimits und Prioritätsgebühr mit null angeben.

Anwendungen, die V1-Transaktionen erstellen, müssen ihre Limits für Compute Units und geladene Kontodaten ausdrücklich festlegen. Beide Werte sind im neuen Format standardmäßig null. Werden sie nicht angegeben, kann die Transaktion vor ihrer Ausführung fehlschlagen.

Transaktionen mit mehr als 1.232 Bytes müssen außerdem mit Base64-Kodierung eingereicht werden. Für den Base58-Einreichungspfad gilt weiterhin die frühere Größenbeschränkung.

V1 bietet mehr Platz, verändert aber andere Grenzen

V1 ist nicht einfach V0 mit einer größeren Datenmenge. Das Format kann bis zu 64 Konto-Adressen direkt in der Transaktion enthalten, unterstützt jedoch keine Address Lookup Tables. Doppelte Konto-Adressen werden ebenfalls abgelehnt.

Diese Regeln führen für Anwendungsteams zu einer anderen Designentscheidung. V0 bleibt nützlich, wenn Lookup Tables eine effiziente Möglichkeit bieten, auf Konten zu verweisen. V1 ist dagegen für Vorgänge gedacht, die stärker von zusätzlichem Platz für Anweisungen, Signaturen oder Beweise profitieren.

Eine einfache Zahlung dürfte vom neuen Format kaum profitieren. V1 eignet sich eher für Anwendungen, die eine komplexe Abfolge ersetzen oder Daten aufnehmen können, die zuvor überhaupt nicht in eine Transaktion passten.

Größere Transaktionen können höhere Gebühren verursachen

Die Erhöhung des Byte-Limits macht nicht automatisch jede V1-Transaktion teurer. Die Kosten hängen von den angeforderten Ressourcen, der Zahl der Signaturen und der von der Anwendung gewählten Prioritätsgebühr ab.

Größere Nachrichten beanspruchen jedoch mehr Bandbreite der Validatoren. Laut Solanas Dokumentation wird der Scheduler voraussichtlich eine höhere Prioritätsgebühr für eine größere Transaktion verlangen als für eine kleinere Transaktion mit gleichwertigem Prioritätsziel, insbesondere wenn Blockspace knapp ist.

V1 gibt die Prioritätsgebühr als Gesamtbetrag in Lamports an. V0 verwendet einen Preis pro Compute Unit. Analyseplattformen müssen die beiden Formate daher normalisieren, bevor sie sie miteinander vergleichen können.

Der Bedarf an Prioritätsgebühren kann sich mit der Netzwerkaktivität deutlich verändern, wie Solanas aktuelle Gebührendaten zeigen. Entwickler müssen daher den Komfort eines einzigen größeren Vorgangs gegen die Kosten abwägen, die für dessen Aufnahme in Zeiten hoher Auslastung anfallen.

Die Aktivierung startet den Einführungstest

Das Upgrade beseitigt eine Einschränkung, die zuvor die Entwicklung von Solana-Anwendungen geprägt hat. Die Aktivierung auf dem Mainnet garantiert jedoch keine breite Nutzung. Wallets, RPC-Anbieter, Indexer und Anwendungsbibliotheken müssen das neue Format korrekt verarbeiten, bevor Entwickler es in kundenorientierten Produkten zuverlässig einsetzen können.

Die ersten Vorteile könnten bei Workloads sichtbar werden, die bereits mit der früheren Grenze zu kämpfen haben, darunter vertrauliche Überweisungen, institutionelle Multisig-Vereinbarungen und anweisungsintensive Anwendungen. Für gewöhnliche Überweisungen bleiben die etablierten Formate die einfachere Option.

Die Bedeutung von V1 wird davon abhängen, ob die Abwicklung dieser Workloads in einer atomaren Transaktion genügend Einsparungen bei Koordination, Signaturen und fehlgeschlagenen Versuchen ermöglicht, um die erforderlichen Aktualisierungen der Infrastruktur zu rechtfertigen.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar. Wallet-Kompatibilität, Anwendungsunterstützung und Transaktionsgebühren können sich ändern.

Quelle: Coindoo