cryptopolitan.com
Solana wird voraussichtlich am 9. September die Datenmenge, die eine einzelne Transaktion übertragen kann, verdreifachen. Diese neue Obergrenze von 4.096 Byte passt laut dem SIMD-0296-Vorschlag auf GitHub in eine einzelne 4 KiB große Speicherseite der Validator-Hardware.
Workloads, die mehrere Transaktionen erfordern, können jetzt mit einem einzigen atomaren Aufruf abgeschlossen werden.
QUIC machte die Beschränkung auf 1.232 Byte sinnlos
Die ursprüngliche Beschränkung von Solana war eine Vorsichtsmaßnahme im Netzwerkbereich. Das Netzwerk arbeitete mit einer IPv6-MTU von 1280 Byte.
Damit blieben nach Abzug des Protokoll-Overheads 1.232 Byte für die Transaktionsnutzdaten übrig, schreiben die Autoren von SIMD-0296. Das ist plausibel, da jede Nachricht die MTU ohne Fragmentierung durchlaufen musste.
Solana hat 2022 auf QUIC als Standardverfahren für die Transaktionsabwicklung umgestellt. RFC 9000 legt keine maximale Streamgröße fest, sodass größere Nutzdatenmengen problemlos auf Netzwerkebene übertragen werden können.
Die Beschränkung auf 1.232 Bytes hatte sich zu einer Regel entwickelt, die keine technische Grundlage mehr hatte.
Die beiden Dokumente wurden von den Anza-Ingenieuren Jacob Creech und Andrew Fitzgerald verfasst. SIMD-0296 erhöht die Größenbeschränkung.
Ein zugehöriger Standard, SIMD-0385, defidas v1-Nachrichtenformat, das die zusätzlichen Bytes enthält. Dieses Paar löst ein Problem, das Entwickler seit dem Start der Blockchain umgangen haben.
Der Vorschlag sieht eine Transaktionsgröße von 4.096 Bytes gegenüber der von QUIC maximal zulässigen Größe vor, sodass eine Transaktion in eine einzelne Standardseite von 4 KiB im Validatorspeicher passt. Keine Transaktion überschreitet jemals eine Seitengrenze.
Die Speicherverwaltung pro Transaktion ist gering. Jede Transaktion ist auf eine einzelne Seite beschränkt.
Um die Grenze von 4.096 Byte zu ermitteln, analysierten Creech und Fitzgerald, wie Entwickler Jito-Bundles nutzten, um die alten Beschränkungen zu umgehen:
- 50 % der eingereichten Pakete waren 2.048 Byte oder kleiner.
- 65 % waren kleiner als 6.144 Bytes.
- 100 % blieben unter 9.216 Bytes.
Eine Obergrenze von 4.096 Byte deckt die überwiegende Mehrheit dieser Multi-Transaktions-Workloads in einem einzigen Aufruf ab und bleibt dabei innerhalb der Hardware-Seitenbeschränkungen des Validators.
Unvorbereitete RPC-Aufrufe lösen nun den Fehler -32015 auf Solana aus
Die zusätzliche Kapazität ermöglicht Workloads, die die Grenze von 1.232 Byte überschreiten.
Bei Zero-Knowledge-Beweisen, wie sie beispielsweise in Token Extensions'dentTransfers verwendet werden, wurden Nutzdaten erzeugt, die das Limit von 1.232 Byte überschritten.
Um dieses Problem zu lösen, verketteten Entwickler mehrere Aufrufe oder verzichteten auf atomare verschlüsselte Übertragungen. Das neue Limit von 4.096 Byte ermöglicht Zero-Knowledge-Beweise in einer einzigen Transaktion.
Die BLS-Signaturaggregation und große Multisig-Konfigurationen profitieren ebenfalls von dieser Änderung. SIMD-0296 nennt verschachtelte Multisig-Systeme, die von institutionellen Finanzabteilungen und DAOs über Squads verwendet werden, als einen der Hauptgründe.
Es wird auch auf Winternitz-Einmalsignaturen und On-Chain-BLS-Schemata verwiesen, die ohne Vorkompilierung funktionieren.
Das Format verzichtet auf die Adresstabellen, die in Version 0 für bis zu 64 Konten mit kurzen Indizes verwendet wurden. Die Tabellen erhöhen die Komplexität unnötig, da nun 64 32-Byte-Adressen in einer Zeile verwendet werden, die nur 2.048 Byte belegen und damit deutlich unter dem Limit liegen.
Die Beschränkung auf 64 Konten pro Transaktion bleibt im Solana Netzwerk bestehen. Anwendungen mit hohem Kontoaufkommen werden diese Grenze auch nach Behebung des Byte-Budget-Problems weiterhin erreichen.
Mit Jito-Bundles können Entwickler bis zu fünf Transaktionen zu einer Alles-oder-Nichts-Sequenz zusammenführen, um das Problem der Byte-Beschränkung zu lösen.
Transaction v1 erzielt dasselbe atomare Ergebnis in einer einzigen Transaktion. Es bringt native Atomizität direkt in die Basisschicht.
V1 ist für Absender optional, daher funktionieren ältere Transaktionen und V0-Transaktionen weiterhin. Laut den Migrationshinweisen der Solana handelt Solana es sich um eine grundlegende Änderung für Infrastrukturen, die Blöcke lesen.
Wenn die Datentools und Block-Explorer nicht für die neue Version von Solanaaktualisiert werden, frieren sie entweder vollständig ein oder geben Fehlermeldungen aus.
Wenn eine App versucht, eine v1-Transaktion oder einen Block ohne den Parameter für die neue Version zu lesen, lehnen die Server von Solanadie Anfrage mit dem Systemfehlercode -32015 ab.
Tools, die kontinuierlich Live-Blöcke streamen, stoßen auf eine neue v1-Transaktion, erhalten eine völlig leere Antwort und bleiben dort hängen.
Indexierer, also Tools, die Transaktionsdaten aufzeichnen, zeigen für neue Transaktionen keine Prioritätsgebühren an, weil sie am falschen Ort suchen.
Früher wurden diese Gebühren einer speziellen Liste innerhalb der Transaktion entnommen. In der neuen Version werden diese Informationen in einem eigenen Übersichtsfeld angezeigt.
Anza verlangt von RPC-Anbietern ein Upgrade auf Agave v4.2. Helius hat eine Migrations-Checkliste mit detaillierten Anweisungen herausgegeben.
Die Transaktion v1 wurde am 1. September während der Epoche 1025 im Solana -Testnetz aktiviert. Anza hat die Bereitstellung im Hauptnetz offiziell für den 9. September geplant.