Bei dem Aegis-Upgrade jener $DUSK war ich noch am selben Tag dran und habe das Knoten-Panel beobachtet, bis ich fertig war – offiziell wird das ganz offen so gesagt: „ein verpflichtendes Upgrade für alle Betreiber von Knoten“. Wer nicht upgraden würde, fliegt nach dem Hard-Fork beim Aktivieren direkt aus dem Netzwerk, ohne dass es eine Übergangsfrist gäbe, in der man wählen könnte.
Ich habe dann im Changelog von Rusk v1.7.0 nachgeschaut und gemerkt, dass in diesem Upgrade eine eher unscheinbare, aber ziemlich entscheidende Korrektur steckt: in dusk-wallet-core „verhindert, dass die Aggregation der Phoenix-Guthaben bei einem u64-Überlauf einen Wraparound verursacht“. In Klartext: Der frühere Wallet-Code addierte die Guthaben für Phoenix (Dusk’ UTXO-verschlüsseltes Kontomodell) und hatte theoretisch das Risiko eines Zahlenüberlaufs – dann „rundet“ er auf eine sehr kleine oder sogar falsche Zahl zurück. Dieses Upgrade stopft genau diese Schwachstelle.
Innerhalb der gleichen Änderungen gibt es außerdem: die Umstellung der PLONK-Beweisvalidierung auf die V3-Version; einen Größenlimit für den HTTP-Request-Body, um Memory-DoS zu verhindern; und im Wiederherstellungsprozess ein Loch gestopft, das durch unsichere ZIP-Pfad-Querdurchläufe in einen Write-Fehler mündete – alles sehr typische Maßnahmen, um „ein produktionsreifes System abzusichern“, also kein Feature-Update, sondern eine Entschärfung.
Als Betreiber ist für mich aber vor allem das Risiko des Upgrade-Fensters selbst entscheidend: Die Aegis-Aktivierungsblöcke im Mainnet sind 3.590.904, im Testnet 2.773.727 – das ist ein starrer Hard-Fork-Punkt, der nach Blockhöhe festgelegt ist, kein „weiches“ Zeitfenster danach, wann man fertig ist, zu dem es dann gilt. Wenn also ein Teil der Knoten den Upgrade-Abschluss nicht vor dieser Blockhöhe schafft, kann dann kurzzeitig eine uneinheitliche Fork-Konsenslage entstehen? Offiziell heißt es: „Das ist ein infrastructurbasiertes Upgrade, das die Weiche für DuskEVM vorbereitet; es betrifft keine Token-Ökonomie.“ Klingt also nach begrenzter Auswirkung, aber gerade ein verpflichtender Hard-Fork ist – für Netzwerke, denen es an Dezentralisierung nicht ganz hoch geht und in denen die Anzahl der Knoten noch nicht riesig ist – immer ein echter Koordinations-Realitätstest.
#dusk
Dieses Upgrade ist erfolgreich durchgelaufen. In gewisser Weise war das, bevor DuskEVM offiziell gestartet wird, erstmal ein Stresstest für die eigene Basiskonsens- und Speicherschicht. Das Upgrade selbst lief ohne Probleme, aber die vier Wörter „verpflichtender Hard-Fork“ verdienen es, dass wirklich jede Person, die vorhat einen Knoten zu betreiben oder sich auf die Determinismus-Zusicherung der Dusk-Abrechnung verlässt, einmal genauer hinsieht. @Dusk
Ich habe dann im Changelog von Rusk v1.7.0 nachgeschaut und gemerkt, dass in diesem Upgrade eine eher unscheinbare, aber ziemlich entscheidende Korrektur steckt: in dusk-wallet-core „verhindert, dass die Aggregation der Phoenix-Guthaben bei einem u64-Überlauf einen Wraparound verursacht“. In Klartext: Der frühere Wallet-Code addierte die Guthaben für Phoenix (Dusk’ UTXO-verschlüsseltes Kontomodell) und hatte theoretisch das Risiko eines Zahlenüberlaufs – dann „rundet“ er auf eine sehr kleine oder sogar falsche Zahl zurück. Dieses Upgrade stopft genau diese Schwachstelle.
Innerhalb der gleichen Änderungen gibt es außerdem: die Umstellung der PLONK-Beweisvalidierung auf die V3-Version; einen Größenlimit für den HTTP-Request-Body, um Memory-DoS zu verhindern; und im Wiederherstellungsprozess ein Loch gestopft, das durch unsichere ZIP-Pfad-Querdurchläufe in einen Write-Fehler mündete – alles sehr typische Maßnahmen, um „ein produktionsreifes System abzusichern“, also kein Feature-Update, sondern eine Entschärfung.
Als Betreiber ist für mich aber vor allem das Risiko des Upgrade-Fensters selbst entscheidend: Die Aegis-Aktivierungsblöcke im Mainnet sind 3.590.904, im Testnet 2.773.727 – das ist ein starrer Hard-Fork-Punkt, der nach Blockhöhe festgelegt ist, kein „weiches“ Zeitfenster danach, wann man fertig ist, zu dem es dann gilt. Wenn also ein Teil der Knoten den Upgrade-Abschluss nicht vor dieser Blockhöhe schafft, kann dann kurzzeitig eine uneinheitliche Fork-Konsenslage entstehen? Offiziell heißt es: „Das ist ein infrastructurbasiertes Upgrade, das die Weiche für DuskEVM vorbereitet; es betrifft keine Token-Ökonomie.“ Klingt also nach begrenzter Auswirkung, aber gerade ein verpflichtender Hard-Fork ist – für Netzwerke, denen es an Dezentralisierung nicht ganz hoch geht und in denen die Anzahl der Knoten noch nicht riesig ist – immer ein echter Koordinations-Realitätstest.
#dusk
Dieses Upgrade ist erfolgreich durchgelaufen. In gewisser Weise war das, bevor DuskEVM offiziell gestartet wird, erstmal ein Stresstest für die eigene Basiskonsens- und Speicherschicht. Das Upgrade selbst lief ohne Probleme, aber die vier Wörter „verpflichtender Hard-Fork“ verdienen es, dass wirklich jede Person, die vorhat einen Knoten zu betreiben oder sich auf die Determinismus-Zusicherung der Dusk-Abrechnung verlässt, einmal genauer hinsieht. @Dusk