Solana dimensioniert sein neues 4.096-Byte-Transaktionslimit auf eine Speicherseite

Solana wird am 9. September die Menge an Daten, die eine einzelne Transaktion tragen kann, verdreifachen. Diese neue Obergrenze von 4.096 Bytes passt in eine einzelne 4 KiB-Speicherseite der Validator-Hardware, gemäß dem SIMD-0296-Vorschlag auf GitHub.

Arbeitslasten, die mehrere Transaktionen erfordern, benötigen jetzt einen einzigen atomaren Aufruf zur Fertigstellung.

QUIC machte die 1,232-Byte-Obergrenze sinnlos

Das ursprüngliche Limit von Solana war eine Netzwerksicherheitsmaßnahme. Das Netzwerk operierte mit einer IPv6-MTU von 1.280 Bytes.

Das hinterließ 1.232 Bytes für ein Transaktionspayload nach Protokoll-Overhead, schreiben die Autoren von SIMD-0296. Das ergibt Sinn, wenn jede Nachricht ohne Fragmentierung durch die MTU gehen musste.

Solana wechselte 2022 zu QUIC als Standardmethode zur Abwicklung von Transaktionen. RFC 9000 legt keine maximale Stream-Größe fest, sodass größere Payloads auf Netzwerkebene problemlos durchkommen können.

Das Limit von 1.232 Bytes war zu einer Regel geworden, die keine technische Grundlage hatte.

Die beiden Dokumente wurden von Anza-Ingenieuren Jacob Creech und Andrew Fitzgerald verfasst. SIMD-0296 erhöht die Größenbegrenzung.

Ein Begleitdokument, SIMD-0385, definiert das v1-Nachrichtenformat, das die zusätzlichen Bytes enthält. Das Paar löst eine Einschränkung, die Entwickler seit dem Start der Chain umgangen haben.

Der Vorschlag bevorzugt 4.096 Bytes gegenüber der größten von QUIC erlaubten Größe, damit eine Transaktion in eine einzelne Standard-4-KiB-Seite des Validator-Speichers passt. Keine Transaktion überschreitet jemals eine Seitengrenze.

Die Speicherverwaltung pro Transaktion ist kostengünstig. Jede Transaktion ist auf eine einzelne Seite beschränkt.

Um zur 4.096-Byte-Grenze zu gelangen, analysierten Creech und Fitzgerald, wie Entwickler Jito-Bundles nutzten, um die alten Einschränkungen zu umgehen:

• 50% der eingereichten Bundles waren 2,048 Bytes oder kleiner.
• 65% waren unter 6,144 Bytes.
• 100% blieben unter 9,216 Bytes.

Eine Obergrenze von 4.096 Bytes deckt die große Mehrheit dieser Multi-Transaktions-Arbeitslasten in einem einzigen Aufruf ab, während sie innerhalb der Speicherseitenbeschränkungen der Validator-Hardware bleibt.

Unvorbereitete RPC-Aufrufe werfen jetzt den Fehler -32015 auf Solana

Die zusätzliche Kapazität ermöglicht Arbeitslasten, die das 1.232-Byte-Limit überschreiten.

Zero-Knowledge-Proofs, wie sie bei den Confidential Transfers der Token Extensions verwendet werden, generierten Payloads, die das 1.232-Byte-Limit überschritten.

Um dieses Problem zu lösen, verketteten Entwickler mehrere Aufrufe oder verzichteten auf atomare verschlüsselte Übertragungen. Das neue Limit von 4.096 Bytes ermöglicht Zero-Knowledge-Proofs in einer Transaktion.

BLS-Signaturaggregation und große Multisig-Konfigurationen profitieren ebenfalls von dieser Änderung. SIMD-0296 nennt verschachtelte Multisig, die Art von Multisig, die von institutionellen Schatzmeistern und DAOs über Squads verwendet wird, als einen der Haupttreiber.

Es verweist auch auf Winternitz-Einmal-Signaturen und On-Chain-BLS-Schemata, die ohne Precompiles funktionieren.

Das Format verzichtet auf die Address Lookup Tables, die v0 nutzte, um bis zu 64 Konten mit kurzen Indizes zu referenzieren. Die Tabellen fügen Komplexität hinzu, ohne Nutzen zu bringen, da es jetzt 64 inline 32-Byte-Adressen gibt, die nur 2.048 Bytes belegen, weit unter der Obergrenze.

Die 64-Konten-Begrenzung für jede Transaktion bleibt im Solana-Netzwerk bestehen. Anwendungen mit vielen Konten werden die Grenze auch bei gelöstem Byte-Budget-Problem weiterhin erreichen.

Jito-Bundles ermöglichen es Entwicklern, bis zu fünf Transaktionen zu einer All-or-Nothing-Sequenz zusammenzufassen, um das Byte-Limit-Problem zu lösen.

Transaktion v1 erreicht das gleiche atomare Ergebnis in einer einzigen Transaktion. Sie bringt native Atomarität direkt in die Basisschicht.

V1 ist für Absender optional, daher funktionieren Legacy- und v0-Transaktionen weiterhin. Die Migrationshinweise der Solana Foundation besagen, dass es sich um eine Breaking-Change für Infrastruktur handelt, die Blöcke liest

Wenn Daten-Tools und Block-Explorer nicht für Solanas neue Version aktualisiert werden, frieren sie vollständig ein oder geben Fehler aus.

Wenn eine App versucht, eine v1-Transaktion oder einen Block ohne den neuen Versionsparameter zu lesen, lehnen Solanas Server die Anfrage mit einem Systemfehlercode -32015 ab.

Tools, die Live-Blöcke kontinuierlich streamen, stoßen auf eine neue v1-Transaktion, erhalten eine völlig leere Antwort und bleiben dort hängen.

Indexer, oder Tools, die Transaktionsdaten aufzeichnen, zeigen keine Prioritätsgebühren für neue Transaktionen an, weil sie am falschen Ort suchen.

Sie lasen diese Gebühren früher aus einer speziellen Liste innerhalb der Transaktion. In der neuen Version werden diese Informationen in einer eigenen dedizierten Zusammenfassungsbox gespeichert.

Anza verlangt von RPC-Anbietern, auf Agave v4.2 zu aktualisieren. Helius hat eine Migrations-Checkliste mit den erforderlichen Arbeiten herausgegeben.

Transaktion v1 wurde am 1. September während der Epoch 1025 im Solana-Testnet aktiviert. Anza plante die Mainnet-Bereitstellung offiziell für den 9. September.