Gestern habe ich das neue Coin-Teil $KII nach dem Erhalt kurz abgewartet, und dann habe ich es trotzdem nur für knapp 34u verkauft. Bittere Reue. Angeblich ist es jetzt nur noch 20 wert. Geht es den Brüdern mit Weitblick gut?
Am Freitag habe ich im Büro in Dusk’ GitHub-Issue #2969 gestöbert und diese Zeile „conversion with the incorrect transaction model is not possible“ gesehen. Ich bin ins Grübeln geraten – sogar die offiziellen Testfälle prüfen, dass ein „falsches Transaktionsmodell“ dazu führt, dass die Umwandlung fehlschlägt. Das zeigt: Diese Gas-Matching-Regeln sind so komplex, dass selbst die Entwickler befürchten, dass andere sie falsch anwenden.
Das Dual-Transaction-Modell aus Moonlight + Phoenix ist konzeptionell wirklich elegant. Eines deckt Transparenz ab, das andere schützt die Privatsphäre. Die Börse nutzt Moonlight, normale Nutzer nutzen Phoenix – jeder bekommt, was er braucht.
Aber die Umwandlungslogik erhöht die Systemkomplexität exponentiell. In der Dokumentation der Funktion moonlight_to_phoenix steht eine vernichtende Anmerkung: „moonlight_nonce wird NICHT inkrementiert und muss vom Aufrufer inkrementiert werden“ – der Aufrufer muss das nonce manuell erhöhen, sonst gibt es direkt einen Fehler. Wenn Entwickler diese Kleinigkeit übersehen, bleiben die Gelder der Nutzer mitten im Prozess stecken.
Noch schlimmer: die Gas-Matching-Regeln. Bei der Umwandlung muss das Modell der Geldquelle exakt mit dem Transaktionsmodell übereinstimmen, das das Gas bezahlt. Moonlight → Phoenix geht nur mit einer Moonlight-Transaktion, die das Gas bezahlt – umgekehrt genauso. Entwickler müssen im Code die Umwandlungsrichtung exakt bestimmen; ein einziger Fehler lässt den gesamten Ablauf scheitern.
Der von OtterSec entdeckte PLONK-Fehler zeigt, dass alle Phoenix-Pfade betroffen sind – einschließlich der Phoenix-to-Moonlight-Umwandlung. Ein Exploit, mit dem ein Angreifer scheinbar 60 Millionen US-Dollar „aus dem Nichts“ prägen kann, liegt mindestens zwei Jahre lang in der Validierungslogik. Wenn selbst bei der Kernkryptografie so ein grober Fehler passieren kann, wer kann dann garantieren, dass man die manuellen nonce-Inkremente und die Gas-Matching-Regeln nicht doch falsch umsetzt?
Ein System für beidseitige Umwandlungen, das Entwickler manuell nonce verwalten und Gas-Transaktionsmodelle präzise matchen lässt – bist du sicher, dass das nicht zum Nährboden für systemische Risiken wird?
Das oben ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Sprecht gern im Kommentarbereich mit mir – ist Dusk’ Dual-Model-Umwandlungsdesign eine raffinierte Architektur oder eine Entwickler-Falle?
#dusk $DUSK @Dusk
Am Freitag habe ich im Büro in Dusk’ GitHub-Issue #2969 gestöbert und diese Zeile „conversion with the incorrect transaction model is not possible“ gesehen. Ich bin ins Grübeln geraten – sogar die offiziellen Testfälle prüfen, dass ein „falsches Transaktionsmodell“ dazu führt, dass die Umwandlung fehlschlägt. Das zeigt: Diese Gas-Matching-Regeln sind so komplex, dass selbst die Entwickler befürchten, dass andere sie falsch anwenden.
Das Dual-Transaction-Modell aus Moonlight + Phoenix ist konzeptionell wirklich elegant. Eines deckt Transparenz ab, das andere schützt die Privatsphäre. Die Börse nutzt Moonlight, normale Nutzer nutzen Phoenix – jeder bekommt, was er braucht.
Aber die Umwandlungslogik erhöht die Systemkomplexität exponentiell. In der Dokumentation der Funktion moonlight_to_phoenix steht eine vernichtende Anmerkung: „moonlight_nonce wird NICHT inkrementiert und muss vom Aufrufer inkrementiert werden“ – der Aufrufer muss das nonce manuell erhöhen, sonst gibt es direkt einen Fehler. Wenn Entwickler diese Kleinigkeit übersehen, bleiben die Gelder der Nutzer mitten im Prozess stecken.
Noch schlimmer: die Gas-Matching-Regeln. Bei der Umwandlung muss das Modell der Geldquelle exakt mit dem Transaktionsmodell übereinstimmen, das das Gas bezahlt. Moonlight → Phoenix geht nur mit einer Moonlight-Transaktion, die das Gas bezahlt – umgekehrt genauso. Entwickler müssen im Code die Umwandlungsrichtung exakt bestimmen; ein einziger Fehler lässt den gesamten Ablauf scheitern.
Der von OtterSec entdeckte PLONK-Fehler zeigt, dass alle Phoenix-Pfade betroffen sind – einschließlich der Phoenix-to-Moonlight-Umwandlung. Ein Exploit, mit dem ein Angreifer scheinbar 60 Millionen US-Dollar „aus dem Nichts“ prägen kann, liegt mindestens zwei Jahre lang in der Validierungslogik. Wenn selbst bei der Kernkryptografie so ein grober Fehler passieren kann, wer kann dann garantieren, dass man die manuellen nonce-Inkremente und die Gas-Matching-Regeln nicht doch falsch umsetzt?
Ein System für beidseitige Umwandlungen, das Entwickler manuell nonce verwalten und Gas-Transaktionsmodelle präzise matchen lässt – bist du sicher, dass das nicht zum Nährboden für systemische Risiken wird?
Das oben ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Sprecht gern im Kommentarbereich mit mir – ist Dusk’ Dual-Model-Umwandlungsdesign eine raffinierte Architektur oder eine Entwickler-Falle?
#dusk $DUSK @Dusk
