Je tiefer ich mir Dusk anschaue, desto weniger interessant finde ich die Idee, die da steckt: einfach „mehrere Ausführungsschichten“.

Was für mich besonders auffällt, ist, was Dusk darunter beibehält.

DuskEVM kann Entwicklern die Umgebung geben, die sie bereits kennen. DuskVM kann Anwendungen handhaben, die einen direkteren Zugriff auf die L1 und ihre nativen Fähigkeiten benötigen. Aber keine der beiden wird zur endgültigen Instanz. Diese Rolle bleibt bei DuskDS, das Konsens, Data Availability und Settlement übernimmt.

Ich denke, diese Designentscheidung ist wichtiger, als sie auf den ersten Blick wirkt.

Das bedeutet, dass Dusk ändern kann, wie Anwendungen ausgeführt werden, ohne die Schicht ändern zu müssen, die letztlich dafür zuständig ist, was als endgültig „abgeschlossen“ gilt.

Du kannst diese Beziehung tatsächlich über die Bridge erkennen. DUSK in DuskEVM zu bewegen und wieder zurückzuholen ist nicht nur das Verschieben eines Tokens zwischen zwei Schnittstellen. Ein- und Auszahlungen durchlaufen getrennte Schritte für Bestätigung, Proof und Finalisierung, bevor der Vermögenswert auf der anderen Seite als endgültig gilt.

Und hier gibt es eine Lektion, die ich leicht übersehen kann.

Der Bridge-Vorfall in diesem Jahr zeigte, dass ein funktionierendes Basisprotokoll nicht automatisch jede Schicht darum herum gleich sicher macht. Die Bridge kann Teil der realen Sicherheitsgrenze des Vermögenswerts werden.

Daher ist meine aktuelle Sicht auf Dusk weniger „Privacy-Blockchain“ und mehr diese Frage:

Kannst du das Settlement stabil halten, während sich die Ausführungsumgebung darum herum weiterentwickelt?

#dusk $DUSK @Dusk