SIMD-0683: Solana-Programme sollen Eingabelängen in den Registern r3 bis r5 erhalten
Serguey Asael Shinder2 Min. LesezeitSIMD-0683, „Pass ABIv1 input metadata via registers r3–r5", ist ein Solana Improvement Document, das febo von Anza am 4. Oktober eröffnet und zuletzt am 11. Oktober aktualisiert hat. Der Status lautet Review; der Vorschlag ist weder angenommen noch mit Feature-Gate oder Aktivierungstermin versehen.
Was sich ändert. Startet ein Solana-Programm, übergibt die virtuelle Maschine Informationen über Register. Von den fünf am ABIv1-Einstiegspunkt verfügbaren sind heute zwei belegt: r1 zeigt auf die Eingaberegion, r2 auf die Instruktionsdaten. r3, r4 und r5 enthalten derzeit uninitialisierte Daten. Der Vorschlag belegt sie so: r3 mit der Länge der Instruktionsdaten in Bytes als vorzeichenlose 64-Bit-Zahl in Little Endian; r4 mit einem Zeiger auf den Anfang der Account-Liste in der Eingaberegion; r5 mit der Zahl der Accounts in dieser Liste, Duplikate mitgezählt – derselbe Wert, der schon am Anfang der Eingaberegion steht.
Gesetzt würden die Werte für alle Programme unter allen Loadern, unabhängig davon, ob ein Programm sie liest.
Warum jetzt. Der Vorschlag baut auf dem bereits angenommenen SIMD-0449 („Direct Account Pointers in Program Input") auf, das eine Liste von Account-Zeigern in die Programmeingabe serialisiert, damit Programme den Account-Abschnitt nicht mehr Byte für Byte parsen. Auch mit dieser Liste muss ein Programm aber noch den Offset von den Instruktionsdaten zur Account-Liste berechnen und Längen aus dem Speicher laden. Liegen die drei Werte in Registern, entfallen diese Schritte ganz am Anfang der Ausführung – dem heißesten Pfad jedes Programmaufrufs, auf dem Compute Units verbraucht werden, bevor überhaupt Programmlogik läuft.
Verworfene Alternativen. Nichts zu tun hieße, dass jedes Programm die Eingaberegion weiter selbst parst – angesichts der kleinen Änderung nennt der Vorschlag das unvernünftig. Die Metadaten an den Anfang der serialisierten Eingabe zu verlegen, ginge auch, bräche aber das bestehende Format. Zudem werde das geplante ABIv2 das Eingabelayout ohnehin neu ordnen; SIMD-0683 sei ein sofortiger Gewinn für ABIv1, der dem nicht im Weg steht.
Wen es betrifft. Laut der eigenen Wirkungstabelle ändert sich nur die virtuelle Maschine – nicht Konsens, Block-Packing, Gossip oder Snapshots. Bestehende Programme, die die Register ignorieren, sind nicht betroffen. Programme auf Basis maschinennaher Einstiegs-Frameworks bräuchten ein aktualisiertes SDK, um zu profitieren – und erst, nachdem die Änderung angenommen und im Mainnet aktiviert ist.
Quelle: SIMD-0683 — https://github.com/solana-foundation/solana-improvement-documents/pull/683