Solana-Vorschlag würde Hash-Prüfung bei Programm-Migrationen und -Upgrades ergänzen
Serguey Asael Shinder1 Min. LesezeitSIMD-0690, "Hash-Prüfung bei Programm-Upgrades", befindet sich im Solana-Improvement-Documents-Repository in Prüfung, verfasst von Joe Caulfield und febo von Anza. Der Vorschlag ergänzt einen Hash-Prüfschritt bei nativen und Loader-v2-zu-v3-Programm-Migrationen sowie bei Core-BPF-Programm-Upgrades. Die Begründung ist eine klar benannte Lücke: Migrationen und Upgrades lassen sich nur über ein Feature-Gate aktivieren, doch es gibt derzeit keine Prüfung, dass der Inhalt des Buffer-Kontos tatsächlich den erwarteten Programmdaten entspricht. Der Vorschlag baut auf drei früher angenommenen SIMDs auf — 0088 zur Migration nativer Programme nach Core BPF, 0418 zu Loader-v2-zu-v3-Migrationen und 0495.
Was das bedeutet
Das Risiko ist konkret und genau zu benennen. Ein Feature-Gate steuert, wann eine Migration aktiviert wird, prüft aber nicht, was installiert wird; die Integrität eines Systemprogramm-Austauschs beruht also darauf, dass das Buffer-Konto genau jene Bytes enthält, auf die sich das Netz geeinigt hat. Eine Hash-Prüfung schließt das Fenster zwischen "das Netz hat für die Migration von Programm X gestimmt" und "die Bytes, die zu Programm X wurden, sind die geprüften". Für die betroffenen Programme — native und Core-BPF-Programme sind jene, von denen die ganze Kette abhängt — ist das keine theoretische Feinheit, sondern der Unterschied zwischen einem prüfbaren und einem vertrauensbasierten Upgrade. Der Status ist Prüfung, dies ist also ein Vorschlag, kein ausgeliefertes Verhalten, und als Nächstes zählt, auf welchen Hash man sich festlegt und wann er relativ zur Aktivierung geprüft wird.