#dusk $DUSK Die Erfahrung mit dem DUSK-Knoten ist ziemlich ähnlich wie der Betrieb und die Wartung für eine öffentliche Blockchain, die sich noch schnell weiterentwickelt, und nicht wie bei einem leichten Knoten, den man einfach nur aufsetzt und dann in Ruhe lassen kann. Die Versionsupdates von Rusk erfolgen nicht selten: In jedem Update-Log stecken auch ein paar Konfigurationspunkte, die unbedingt erledigt werden müssen. Wenn man dabei nicht aufpasst, kann man leicht den Anschluss im Testnetz verlieren. Besonders bei Upgrades im DUSK-Netz werden sie typischerweise durch die Blockhöhe ausgelöst – es reicht also nicht, einfach eine konkrete Zeit einzutragen und fertig. Das bedeutet, dass Betreiber die Synchronisierung selbst im Blick behalten müssen, um sicherzustellen, dass der Knoten vor der Zielblockhöhe bereits auf die neue Version umgestellt ist.
Ich bin im DUSK-Testnetz auf einen Fall gestoßen: Nach einem Upgrade stieg die CPU-Auslastung plötzlich stark an, und die Logs waren voller dichter Berechnungen im Zusammenhang mit der Verifikation Zero-Knowledge-Proofs. Wenn man damals nur mit der Mindestkonfiguration lief, kam es leicht zu Verzögerungen in Blöcken, die viele Proof-Validierungen erfordern. Solche Probleme im Testnetz aufzudecken ist grundsätzlich gut – zumindest zeigt das, dass die zugrunde liegende Logik von DUSK nicht statisch ist. Gleichzeitig ist es eine Erinnerung an alle, die am Mainnet-Knoten teilnehmen wollen: Die Anforderungen an die Maschinenkonfiguration und das tägliche Monitoring bei DUSK-Knoten sind höher, als man sich zunächst vorstellt.
Hard Forks wirken in DUSK selbst eher wie ein erzwungener, netzweiter Koordinations-Test. Wenn die Anzahl der Knoten noch nicht riesig ist, kann das Kernteam die Upgrade-Effizienz stärker steuern; aber umgekehrt zeigt das auch, dass die Dezentralisierung sich noch in einer frühen Phase befindet. Was Betreiber tun können, ist: Bei jedem Testnet-Upgrade erst einmal den vollständigen Upgrade-Prozess einmal komplett durchlaufen, Unterschiede in der Konfiguration, das Wachstum der Datenträger und Log-Warnmeldungen dokumentieren. Sonst kann es bei einem wichtigen Upgrade im Mainnet sehr schnell passieren, dass Detailfragen die Stabilität des gesamten Netzwerks beeinträchtigen.
Ich hoffe vielmehr, dass DUSK später feinere Tools für Gesundheitschecks von Knoten und Upgrade-Hinweise bereitstellt – statt dass Betreiber selbst in den Versionslogs herumstöbern müssen. Je stabiler die Netzgrundlage ist, desto eher können später DuskEVM und die Anwendungsschicht ernsthaft in Angriff genommen werden.#dusk @Dusk $DUSK