Solana-v1-Bug kann Reader einfrieren und Gebührenlimits außer Kraft setzen

Das Transaktionsformat v1 von Solana erhöht die maximale Nutzlast von 1.232 auf 4.096 Byte. Der Anstieg beträgt etwa das 3,3-Fache. Legacy- und v0-Transaktionen behalten ihre bisherigen Limits und ihr bisheriges Verhalten. Nutzer und Anwendungen, die diese Formate weiterhin verwenden, müssen nicht migrieren. Auf Solanas Live-Upgrade-Seite war v1 am 4. September im Mainnet als inaktiv aufgeführt. Das Testnet war aktiv. Das Devnet war in Epoche 1140 live. Ein am 28. August veröffentlichtes Solana-Änderungsprotokoll beschrieb v1-Transaktionen als in Kürze verfügbar. RPC-Nutzer müssen das Format unterstützen, bevor sie v1-Daten lesen. Das Opt-in teilt dem RPC-Dienst lediglich mit, welches höchste Format der Client decodieren kann. Es fordert keine v1-Daten an und ändert nicht, wie Legacy- und v0-Transaktionen zurückgegeben werden. Bei v1 werden Limits für Compute Units, geladene Account-Daten und Prioritätsgebühren in ein Objekt statt in Instruktionen verschoben. Indexer, die weiterhin Instruktionen durchsuchen, können für jede v1-Transaktion ein Compute-Budget von null melden, ohne einen Fehler auszulösen. Das Protobuf-Flag ist sowohl für v0 als auch für v1 auf true gesetzt. Ein veralteter Geyser- oder gRPC-Nutzer kann v1 daher als v0 kennzeichnen und ein leeres Budget beibehalten. Nutzer müssen die Protobuf-Stubs neu erzeugen und vor dem Lesen des Flags Feld 7 prüfen. Relayer, Paymaster und andere Server-Signer müssen ihre Richtlinienprüfungen aktualisieren. Ein Sponsor, der Instruktionen auf eine Gebührenobergrenze durchsucht, kann eine verbindliche Obergrenze möglicherweise nicht mehr durchsetzen, weil diese Instruktionen bei v1 vorkommen, aber als No-op ausgeführt werden können. Server müssen das v1-Präfix erkennen und Gebühren- sowie Ressourcenlimits in der Transaktionskonfiguration durchsetzen. Der Artikel charakterisiert dies als Versagen der Anwendungskontrolle und nicht als Konsensfehler. Er erklärt, dass das Problem kein Beleg dafür ist, dass Gelder automatisch gefährdet sind. Solana zufolge stellt derzeit kein Sysvar und kein Syscall die v1-Nachrichtenkonfiguration bereit. Programme, die ihr Verhalten anhand introspektierter Instruktionen steuern, müssen sich beim Livegang von v1 auf diese Prüfung nicht mehr verlassen. Als Mindestversionen mit Lesefähigkeit werden 8.0.0, 3.0.0-rc.3, Rust 4.2.x, Python 0.29.0 und 1.23.0 genannt. Die 1.x-Linie von web3.js kann v1 ab 1.99.0-beta.0 lesen, aber nicht erstellen, signieren oder senden. Yellowstone-Nutzer benötigen je nach Stack mindestens 12.6.0, das Geyser-Plugin 15.1.1, den gRPC-Client 12.0.0 oder 6.0.0. Das Erstellen von v1-Transaktionen ist optional. Teams, die sie erstellen, müssen die Limits für Compute Units und geladene Account-Daten ausdrücklich setzen, da beide standardmäßig null sind. Sie müssen No-op-Instruktionen entfernen. Sie müssen auf die Verwendung von Address-Lookup-Tabellen verzichten. Für Nutzlasten von mehr als 1.232 Byte müssen sie Base64 verwenden. Die unmittelbare Frist ist ein Kompatibilitätstest für Dienste, die möglicherweise die v1-Transaktion eines anderen Nutzers lesen, indexieren oder sponsern.