Dusk hat eine sehr auffällige Eigenschaft in seiner aktuellen Architektur – es wird ganz bewusst „zerlegt“.
Im Gegensatz zu den meisten öffentlichen Ketten, die Konsens, Ausführung und Abrechnung in einen monolithischen Stack stopfen, trennt Dusk diese drei Dinge voneinander. Ganz unten liegt DuskDS, das den Konsens, die Datenverfügbarkeit und die Abrechnung übernimmt; in der Mitte ist ein DuskEVM eingehängt, das vollständig mit Solidity kompatibel ist, sodass Entwickler, die von Ethereum migrieren, ihren Code nahezu nicht ändern müssen; ganz oben gibt es noch eine Schicht namens DuskVM, die speziell dafür ausgelegt ist, native Privacy-Anwendungen auszuführen. Drei Schichten, die jeweils ihren Aufgabenbereich haben, verbunden über denselben DUSK-Token.
Die Motivation für diese Entscheidung ist nicht schwer zu verstehen. Eine Kette aufzubauen, die komplett in sich geschlossen ist, hat als größten Preis, dass Entwickler ihre Toolchain neu lernen müssen, und die Ökosystembildung wird sehr langsam anlaufen. Wenn man hingegen die EVM-Schicht „draufsetzt“, können Solidity, Hardhat, MetaMask und andere bestehende Dinge direkt genutzt werden; dadurch sinkt die Reibung bei der Anwerbung von Entwicklern.
Doch die Kosten dieser Entscheidung sind ebenso direkt – die Komplexität steigt, und zwar an der kritischsten Stelle.
Der Fluss von Assets zwischen den Schichten bedeutet neue Vertrauensannahmen und eine größere Angriffsfläche. Wenn Assets zwischen DuskDS und DuskEVM zirkulieren, braucht es eine native Bridging-Integration; obwohl dafür weder Asset-Umhüllungen noch Custodians erforderlich sind, führt der Cross-Layer-Transfer an sich zusätzliche Prüf-/Validierungsstufen ein. In den vergangenen Jahren sind Vorfälle, die durch Cross-Layer-Design verursacht wurden, viel zahlreicher gewesen als solche, die direkt aus dem Virtual-Machine-Teil selbst entstanden.
Da ist noch ein Problem, das leicht übersehen wird: die Verteilung der Knoten. Dusk verwendet SBA als Konsens – das bedeutet, dass Knoten dauerhaft online sein müssen und die Konfiguration korrekt eingerichtet sein muss. Diese Schwellen sichern zwar die Sicherheit des Netzwerks, aber sie bedeuten auch, dass die Hardware- und Betriebs-/Wartungskosten für normale Teilnehmer, um dauerhaft selbst Knoten zu betreiben, nicht gerade gering sind. Wenn sich Knoten mit der Zeit immer mehr bei einer kleinen Zahl großer Anbieter konzentrieren, wird auch die beste Architektur ihr „Gespür“ verlieren.
Deshalb schaue ich mir Dusk heute an – der Schwerpunkt liegt nicht darauf, wie viele Schichten es hat oder wie hoch die TPS sind. Ich betrachte zwei Dinge: Erstens, ob der Asset-Status über die Schichten hinweg und die Datenschutz-/Privacy-Grenzen klar erklärt sind; zweitens, welche Anwendungsarten auf der EVM-Schicht entstehen – wenn es am Ende nur lauter übernommene allgemeine Protokolle sind, dann ist die Modularität lediglich eine andere Art von Vermarktung; wenn es hingegen wirklich Anwendungen gibt, die die zugrunde liegenden Vertraulichkeitsfunktionen ansteuern (z. B. mit Hedger verschlüsselte Orderbücher oder mit dem XSC-Standard vertrauliche Wertpapiere), dann zeigt das, dass die Differenzierung dieser Architektur tatsächlich in der Praxis genutzt wird.
Nachdem die Architektur steht, bleibt die Frage, was oben herauswachsen kann.
#dusk $DUSK @Dusk
Im Gegensatz zu den meisten öffentlichen Ketten, die Konsens, Ausführung und Abrechnung in einen monolithischen Stack stopfen, trennt Dusk diese drei Dinge voneinander. Ganz unten liegt DuskDS, das den Konsens, die Datenverfügbarkeit und die Abrechnung übernimmt; in der Mitte ist ein DuskEVM eingehängt, das vollständig mit Solidity kompatibel ist, sodass Entwickler, die von Ethereum migrieren, ihren Code nahezu nicht ändern müssen; ganz oben gibt es noch eine Schicht namens DuskVM, die speziell dafür ausgelegt ist, native Privacy-Anwendungen auszuführen. Drei Schichten, die jeweils ihren Aufgabenbereich haben, verbunden über denselben DUSK-Token.
Die Motivation für diese Entscheidung ist nicht schwer zu verstehen. Eine Kette aufzubauen, die komplett in sich geschlossen ist, hat als größten Preis, dass Entwickler ihre Toolchain neu lernen müssen, und die Ökosystembildung wird sehr langsam anlaufen. Wenn man hingegen die EVM-Schicht „draufsetzt“, können Solidity, Hardhat, MetaMask und andere bestehende Dinge direkt genutzt werden; dadurch sinkt die Reibung bei der Anwerbung von Entwicklern.
Doch die Kosten dieser Entscheidung sind ebenso direkt – die Komplexität steigt, und zwar an der kritischsten Stelle.
Der Fluss von Assets zwischen den Schichten bedeutet neue Vertrauensannahmen und eine größere Angriffsfläche. Wenn Assets zwischen DuskDS und DuskEVM zirkulieren, braucht es eine native Bridging-Integration; obwohl dafür weder Asset-Umhüllungen noch Custodians erforderlich sind, führt der Cross-Layer-Transfer an sich zusätzliche Prüf-/Validierungsstufen ein. In den vergangenen Jahren sind Vorfälle, die durch Cross-Layer-Design verursacht wurden, viel zahlreicher gewesen als solche, die direkt aus dem Virtual-Machine-Teil selbst entstanden.
Da ist noch ein Problem, das leicht übersehen wird: die Verteilung der Knoten. Dusk verwendet SBA als Konsens – das bedeutet, dass Knoten dauerhaft online sein müssen und die Konfiguration korrekt eingerichtet sein muss. Diese Schwellen sichern zwar die Sicherheit des Netzwerks, aber sie bedeuten auch, dass die Hardware- und Betriebs-/Wartungskosten für normale Teilnehmer, um dauerhaft selbst Knoten zu betreiben, nicht gerade gering sind. Wenn sich Knoten mit der Zeit immer mehr bei einer kleinen Zahl großer Anbieter konzentrieren, wird auch die beste Architektur ihr „Gespür“ verlieren.
Deshalb schaue ich mir Dusk heute an – der Schwerpunkt liegt nicht darauf, wie viele Schichten es hat oder wie hoch die TPS sind. Ich betrachte zwei Dinge: Erstens, ob der Asset-Status über die Schichten hinweg und die Datenschutz-/Privacy-Grenzen klar erklärt sind; zweitens, welche Anwendungsarten auf der EVM-Schicht entstehen – wenn es am Ende nur lauter übernommene allgemeine Protokolle sind, dann ist die Modularität lediglich eine andere Art von Vermarktung; wenn es hingegen wirklich Anwendungen gibt, die die zugrunde liegenden Vertraulichkeitsfunktionen ansteuern (z. B. mit Hedger verschlüsselte Orderbücher oder mit dem XSC-Standard vertrauliche Wertpapiere), dann zeigt das, dass die Differenzierung dieser Architektur tatsächlich in der Praxis genutzt wird.
Nachdem die Architektur steht, bleibt die Frage, was oben herauswachsen kann.
#dusk $DUSK @Dusk
