SIMD-0690: Solana soll vor dem Austausch eines Kernprogramms einen SHA-256-Hash prüfen
Serguey Asael Shinder2 Min. LesezeitSIMD-0690, am 7. Oktober von febo (Anza) eröffnet, schlägt einen kleinen Sicherheitsschritt für einen der heikelsten Vorgänge auf Solana vor: die Migration eines bestehenden Programms vom alten Loader v2 auf Loader v3. Der Vorschlag steht auf Review und ist noch nicht angenommen; am 11. Oktober vermerkte der SIMD-Bot die Zustimmung des Reviewers topointon-jump, die Zustimmung der zuständigen Anza-Reviewer fehlte noch.
Worauf er aufbaut. Nach dem bereits angenommenen SIMD-0418 wird ein Loader-v2-Programm migriert, indem man ein Buffer-Konto mit den neuen Programmbytes vorbereitet. Wird ein eigenes Feature Gate aktiv, ersetzt die Laufzeit das alte Programmkonto durch neue Loader-v3-Konten für Programm und Programmdaten, gebaut aus diesem Buffer. Feature Gates sind der Weg, auf dem Solana das Laufzeitverhalten auf allen Validatoren gleichzeitig ändert; ohne eines gibt es keine Migration.
Die Lücke. Bisher prüft nichts, ob der Buffer tatsächlich das Programm enthält, das alle erwarten. Die Migration hängt an der Adresse des Buffers, nicht an seinem Inhalt. Der Sicherheitsabschnitt benennt das Risiko: versehentlicher oder böswilliger Austausch der Programmdaten, auch durch Änderungen an den Bytes zwischen dem Anlegen des Feature Gates und seiner Aktivierung. Da solche Migrationen laut Vorschlag wesentliche Programme ersetzen, läge bei einem falschen Buffer unerwarteter Code dort, wo Kernfunktionen laufen.
Die Prüfung. Zusammen mit dem Feature Gate wird ein SHA-256-Hash des erwarteten Programms (der ELF-Bytes) hinterlegt. Bei Aktivierung extrahiert die Laufzeit die ELF-Bytes aus dem Buffer ohne nachgestellte Nullbytes, hasht sie mit SHA-256 und vergleicht das Ergebnis mit dem erwarteten Wert. Stimmen sie überein, läuft die Migration genau wie in SIMD-0418 beschrieben. Stimmen sie nicht, schlägt sie fehl und das bestehende Programm bleibt unverändert. Betroffen ist nur die Transaktionsausführung der Laufzeit; der Autor nennt keine inkompatiblen Änderungen, da der Schritt nur bei Aktivierung eines Migrations-Feature-Gates läuft. Die Alternative – weiter ohne Prüfung – verwirft der Text wegen des Risikos, falsche Programmdaten in wichtige Programme zu migrieren.
Wie der Hash geliefert wird, überlässt der Vorschlag den Validator-Implementierungen: Er sei mit dem Feature Gate „in accordance with the validator implementation“ bereitzustellen. Jeder Validator-Client muss also festlegen, wo der erwartete Wert liegt – das Detail, auf das man bei der Umsetzung achten sollte.
Warum das über Solana hinaus zählt. Eingebaute Programme einer Chain zu aktualisieren ist ein Governance-Akt, der in Code vollzogen wird. Die Bindung an einen vorab festgelegten Hash macht aus „wir aktivieren das Feature für dieses Konto“ ein „wir aktivieren es für genau diese Bytes“ – dieselbe Idee wie eine Abhängigkeit per Prüfsumme statt per Name festzunageln.
Quelle: SIMD-0690, Hash validation in v2 program migrations, Pull Request vom 7. Oktober 2026 — https://github.com/solana-foundation/solana-improvement-documents/pull/690 ; Diskussion — https://github.com/solana-foundation/solana-improvement-documents/discussions/689