#dusk $DUSK @Dusk
Ich habe angefangen, unabhängige Routen in DuskEVM zu zählen – und nun, die Liste wurde sehr schnell kurz. DUSK-Dokumente zeigen Nutzer auf genau einen RPC, einen Explorer, einen Web-Wallet-Bridge-Flow und den Sequencer in der Einzahl.

DuskDS kann weiterhin Batches über dezentrale Konsensmechanismen abwickeln. Aber wenn ein Sequencer Transaktionen einordnet, ein Standard-Endpunkt Einreichungen entgegennimmt und eine offizielle Oberfläche Nutzer darüber informiert, wann Bridge-Abhebungen bereit sind, dann gibt es eine Koordinationsschicht oberhalb des Konsenses. Sie schreibt möglicherweise keinen endgültigen Zustand um. Sie kann jedoch weiterhin verzögern, filtern oder verschwinden.

Das ist für DUSK relevant, weil der Gasbedarf und die Bridge-Liquidität davon abhängen, dass Nutzer die Ausführung erreichen – nicht davon, dass Bereitsteller darunter weiter finalisieren. Das Design verteilt die Abwicklung; der praktische Weg kann den Zugriff jedoch über offizielle Infrastruktur konzentrieren. Unterschiedliches Ding.

Die meisten Menschen verwechseln verifizierte Abwicklung mit neutralem Zugang. Das sind nicht die gleichen Dinge. Der gleiche Test sollte alle Peer-Cluster abdecken, die Credential-Aussteller von Citadel und die 90/10-Top-up-Regel: die zehn Bereitsteller, die gemeinsam gehostet werden, sind nicht zehn unabhängige Fehlerdomänen.

Meine stille Sorge gilt den fehlenden Daten. Ich finde keine öffentlichen Angaben zu RPC-Verkehrsanteilen, keine medianen Peer-Zahlen, keine Details zum Sequencer-Failover oder zu den Schwellenwerten für die Bridge-Steuerung. Solange DUSK diese nicht offenlegt, beschreibt die Dezentralisierung eher die Schicht der Abwicklung als die vollständige Nutzerreise – und das deutlich verlässlicher.