ZIP-215 wörtlich würde Solanas System Program ID signierbar machen
Serguey Asael Shinder2 Min. LesezeitPR #616 schreibt den Kern von SIMD-0376 neu - 351 Zeilen hinzu, 57 entfernt in proposals/0376-verify-strict.md - und die Änderung ist eine Verengung, keine Kehrtwende.
Der frühere Text ersetzte Solanas heutige verify_strict-Semantik, geerbt aus Agaves Verwendung von ed25519-dalek, durch ZIP-215, die EdDSA-Variante von Zcashs Zebra: die Torsionsprüfungen für $R$ und $A$ entfallen, die Verifikationsgleichung wird mit dem Kofaktor multipliziert, die Prüfung wird gegenüber Torsionselementen unempfindlich. Der geänderte Text spezifiziert stattdessen das ***kofaktorierte* Verfahren aus "Taming the many EdDSAs" (eprint 2020/1244) - also die kofaktorierte Gleichung von ZIP-215, verbunden mit ausdrücklicher Ablehnung nicht-kanonischer Kodierungen sowie von $A$ und $R$ kleiner Ordnung**. Die Wirkung wird genau beschrieben: die Prüfung wird unempfindlich gegenüber den Torsions*komponenten* ansonsten gültiger Punkte, nicht aber gegenüber Punkten, die vollständig Torsion sind.
Der Grund für die Abweichung steht ausdrücklich im Text, und das ist der mitzunehmende Teil. Der Vorschlag übernimmt ZIP-215 bewusst nicht wörtlich, weil ZIP-215 ein $A$ kleiner Ordnung akzeptiert - was auf Solana Pubkey::default(), die Kodierung aus Nullen und zugleich die System Program ID, zu einem signierbaren öffentlichen Schlüssel machen würde.
Die genannten Vorteile bleiben: Batch-Verifikation von Transaktionssignaturen, effizientere Validatoren und über Implementierungen hinweg standardisiertes Konsensverhalten.
Was das bedeutet
So sieht es aus, wenn eine Chain aufhört, ihre Konsensregeln von einer Bibliothek zu erben, und sie aufschreibt. verify_strict war nie eine Spezifikation, sondern das, was ed25519-dalek zufällig implementierte - zum Konsens erhoben, weil alle diesen Code ausführten. Es durch eine zitierte Gleichung plus benannte Ablehnungskriterien zu ersetzen bedeutet, dass eine zweite Implementierung aus dem Dokument geschrieben werden kann statt durch Lesen von Agave. Das ist die Voraussetzung dafür, überhaupt mehr als einen Validator-Client zu haben.
Das besserere Argument für die Arbeit ist aber der Befund zu Pubkey::default(). Ein gut geprüfter, breit implementierter Standard einer benachbarten Chain trifft auf eine Konvention Solanas - und zusammen ergeben sie eine signierbare System Program ID. Diese Tatsache steht in keiner der beiden Spezifikationen und erscheint nur, wenn man beide gleichzeitig hält. An ZIP-215 ist nichts falsch, und daran, den Nullschlüssel als Programm-Kennung zu benutzen, ebenso wenig. Der Defekt sitzt in der Naht, und genau dort scheitern importierte Spezifikationen.
Bemerkenswert ist auch die Ehrlichkeit des verbleibenden Vorbehalts: unempfindlich gegenüber Torsions*komponenten*, nicht gegenüber vollständig torsionalen Punkten. Genau diese Unterscheidung fällt in Zusammenfassungen weg und wird dann falsch implementiert - SIMD-0376 schreibt sie jetzt aus, statt sie dem Leser zu überlassen.