SIMD-0670: schlankerer CPI-Syscall spart bis zu 55 Prozent Aufwand
Serguey Asael Shinder2 Min. LesezeitEin neues Solana Improvement Document, SIMD-0670, schlägt eine zweite Version des Syscalls vor, mit dem Programme andere Programme aufrufen. Eingereicht hat ihn am 25. September febo von Anza, der Entwickler hinter der Programmbibliothek Pinocchio; er befindet sich in Prüfung. Laut Pull-Request folgt er einer Diskussion, in der man sich darauf einigte, Konten über ihren Index in der Instruktion zu benennen.
Das Problem ist, wie viel Arbeit ein programmübergreifender Aufruf (CPI) einem Programm abverlangt, bevor er stattfindet. Heute übergeben Programme mit der aktuellen ABI zwei Listen von Kontodaten - AccountMeta und AccountInfo - und müssen erhaltene Kontoinformationen in ein anderes Format umwandeln, das die Laufzeit danach erneut umwandelt. Der Vorschlag beziffert das auf 90 Byte pro Konto und CPI: 34 für die Meta- und 56 für die Info-Struktur. Bei bis zu 255 Konten pro CPI und einer Stack-Grenze von 4.096 Byte müssen Programme oft auf dem Heap allokieren.
Der neue sol_invoke_signed_v2 erhält eine CpiInstruction mit einer einzigen Liste von CpiAccount-Einträgen, jeder nur ein Kontoindex plus Schreib- und Signatur-Flag: 4 Byte statt 90. Die Laufzeit hat die Kontodaten ohnehin und sucht sie über den Index. Laut Vorschlag bleibt die CPI-Logik der Laufzeit ansonsten unverändert; nur die virtuelle Maschine erhält einen neuen Syscall. Der Benchmark, ein Pinocchio-Programm, das ein minimales Ziel aufruft, zeigt bei acht Konten einen Rückgang von 1.376 auf 1.174 Compute Units, 15 Prozent, und bei 64 Konten von 2.813 auf 1.267, 55 Prozent. Weil Indizes bei bekannter Kontoliste zur Kompilierzeit feststehen, lässt sich die Liste statisch aufbauen.
Was das bedeutet
Compute Units sind das, wofür Solana-Programme zahlen, und CPIs sind überall: Token, Swaps und Kreditprotokolle rufen alle andere Programme auf. Eine Ersparnis, die mit der Zahl der Konten wächst, zählt am meisten bei komplexen Transaktionen, die schon an Grenzen stoßen.
Es ist ein Vorschlag in Prüfung, keine geplante Änderung. Er bräuchte Annahme, ein Feature-Gate und Aktivierung, und Programm-Frameworks müssten den neuen Aufruf übernehmen. Der alte Syscall bleibt, Programme, die nicht wechseln, brechen also nicht.