Ich habe mir die modulare Architektur von Dusk wieder angesehen, und das Diagramm ergibt mehr Sinn, wenn man es nicht als drei getrennte Ketten betrachtet.
Es sind wirklich drei verschiedene Aufgaben, die über die Schichten hinweg aufgeteilt werden.
1. DuskDS — die Basisschicht
Das ist die Grundlage.
DuskDS ist verantwortlich für die grundlegenden Netzwerkfunktionen rund um:
* Konsens
* Datenverfügbarkeit
* Abrechnung
Statt jede Ausführungsverantwortung in die Basisschicht zu legen, konzentriert sich DuskDS darauf, das zugrunde liegende System zu koordinieren und abzurechnen.
2. DuskEVM — die Kompatibilitätsschicht
Hier kommt die EVM-Ausführung ins Spiel.
Der interessante Punkt ist nicht nur „Dusk unterstützt EVM“.
Sondern dass die EVM-Ausführung ihre eigene Schicht innerhalb der modularen Architektur erhält und Entwicklern eine vertrautere Umgebung bietet, während die zugrunde liegende DuskDS-Schicht getrennt bleibt.
Diese Trennung kann die Menge an Integrationsaufwand reduzieren, die beim Bauen von Anwendungen nötig ist.
3. DuskVM — die Privacy-Execution-Schicht
Dann gibt es DuskVM.
Seine Aufgabe ist wieder eine andere: datenschutzorientierte Ausführung.
Die Architektur zwingt also nicht, dass öffentliche EVM-ähnliche Ausführung und datenschutzorientierte Ausführung exakt in derselben Umgebung stattfinden.
Sie werden in eigene Ausführungspfade getrennt.
Und dann gibt es zwei Bausteine, die das gesamte Design verbinden.
4. Ein DUSK über den gesamten Stack
Die Architektur hält ein einziges DUSK-Token über die Schichten hinweg.
Das ist wichtig, weil modulare Ausführung nicht automatisch bedeutet, dass die Ökonomie fragmentiert wird.
Die Ausführungsumgebungen können getrennt werden, während die Token-Ökonomie einheitlich bleibt.
5. Native Bridge zwischen DuskDS und DuskEVM
Die Schichten sollen außerdem nicht wie isolierte Inseln funktionieren.
Die Architektur beschreibt ein natives Bridge-Konzept zwischen DuskDS und DuskEVM, das der Ausführungsschicht einen Rückweg zum zugrunde liegenden Dusk-System gibt.
Das ist der Teil, der mich mehr interessiert als das Diagramm selbst.
Die Architektur sagt im Grunde:
DuskDS kümmert sich um die Grundlage.
DuskEVM kümmert sich um die EVM-Ausführung.
DuskVM kümmert sich um die datenschutzorientierte Ausführung.
$DUSK #dusk @Dusk
Es sind wirklich drei verschiedene Aufgaben, die über die Schichten hinweg aufgeteilt werden.
1. DuskDS — die Basisschicht
Das ist die Grundlage.
DuskDS ist verantwortlich für die grundlegenden Netzwerkfunktionen rund um:
* Konsens
* Datenverfügbarkeit
* Abrechnung
Statt jede Ausführungsverantwortung in die Basisschicht zu legen, konzentriert sich DuskDS darauf, das zugrunde liegende System zu koordinieren und abzurechnen.
2. DuskEVM — die Kompatibilitätsschicht
Hier kommt die EVM-Ausführung ins Spiel.
Der interessante Punkt ist nicht nur „Dusk unterstützt EVM“.
Sondern dass die EVM-Ausführung ihre eigene Schicht innerhalb der modularen Architektur erhält und Entwicklern eine vertrautere Umgebung bietet, während die zugrunde liegende DuskDS-Schicht getrennt bleibt.
Diese Trennung kann die Menge an Integrationsaufwand reduzieren, die beim Bauen von Anwendungen nötig ist.
3. DuskVM — die Privacy-Execution-Schicht
Dann gibt es DuskVM.
Seine Aufgabe ist wieder eine andere: datenschutzorientierte Ausführung.
Die Architektur zwingt also nicht, dass öffentliche EVM-ähnliche Ausführung und datenschutzorientierte Ausführung exakt in derselben Umgebung stattfinden.
Sie werden in eigene Ausführungspfade getrennt.
Und dann gibt es zwei Bausteine, die das gesamte Design verbinden.
4. Ein DUSK über den gesamten Stack
Die Architektur hält ein einziges DUSK-Token über die Schichten hinweg.
Das ist wichtig, weil modulare Ausführung nicht automatisch bedeutet, dass die Ökonomie fragmentiert wird.
Die Ausführungsumgebungen können getrennt werden, während die Token-Ökonomie einheitlich bleibt.
5. Native Bridge zwischen DuskDS und DuskEVM
Die Schichten sollen außerdem nicht wie isolierte Inseln funktionieren.
Die Architektur beschreibt ein natives Bridge-Konzept zwischen DuskDS und DuskEVM, das der Ausführungsschicht einen Rückweg zum zugrunde liegenden Dusk-System gibt.
Das ist der Teil, der mich mehr interessiert als das Diagramm selbst.
Die Architektur sagt im Grunde:
DuskDS kümmert sich um die Grundlage.
DuskEVM kümmert sich um die EVM-Ausführung.
DuskVM kümmert sich um die datenschutzorientierte Ausführung.
$DUSK #dusk @Dusk