Ich habe Dusk immer wieder als eine weitere Blockchain betrachtet, in die die Privatsphäre direkt eingebaut ist.
Dann habe ich mir die Architektur genauer angesehen, und diese Annahme ließ sich immer schwerer aufrechterhalten.
Eine Sache, die mir aufgefallen ist, ist die Trennung zwischen der Settlement-Schicht von Dusk und seinen Ausführungsumgebungen.
DuskDS übernimmt den zugrunde liegenden Konsens, die Finalität und die Datenverfügbarkeit, während die Ausführung von Smart Contracts in unterschiedlichen Umgebungen erfolgen kann, darunter DuskVM und DuskEVM.
Anfangs habe ich mich gefragt, warum diese Trennung überhaupt nötig ist. Wäre es nicht einfacher, alles in einer einzigen Ausführungsumgebung zu haben?
Dann habe ich jedoch angefangen, über den Zielmarkt von Dusk nachzudenken.
Wenn das Netzwerk darauf abzielt, regulierte Finanzanwendungen zu unterstützen, haben Settlement und Anwendungslogik nicht unbedingt dieselben Anforderungen. Die Schicht, die darüber entscheidet, worüber sich das Netzwerk einigt, benötigt möglicherweise andere Garantien als die Umgebung, in der Entwickler tatsächlich Anwendungen bauen.
Das macht die Architektur für mich noch interessanter.
Dusk versucht nicht nur, Smart Contracts privat zu machen. Es scheint, einige der Verantwortlichkeiten unterhalb der Verträge zu trennen.
Aber da ist noch etwas, das ich besser verstehen möchte.
Führt die Trennung von Settlement und Ausführung dazu, dass regulierte Anwendungen mehr Flexibilität bekommen, oder entsteht dadurch eine weitere Komplexität, mit der Entwickler sich schließlich auseinandersetzen müssen?
Das ist der Teil, in den ich als Nächstes tiefer eintauche.
$DUSK #dusk @Dusk
Dann habe ich mir die Architektur genauer angesehen, und diese Annahme ließ sich immer schwerer aufrechterhalten.
Eine Sache, die mir aufgefallen ist, ist die Trennung zwischen der Settlement-Schicht von Dusk und seinen Ausführungsumgebungen.
DuskDS übernimmt den zugrunde liegenden Konsens, die Finalität und die Datenverfügbarkeit, während die Ausführung von Smart Contracts in unterschiedlichen Umgebungen erfolgen kann, darunter DuskVM und DuskEVM.
Anfangs habe ich mich gefragt, warum diese Trennung überhaupt nötig ist. Wäre es nicht einfacher, alles in einer einzigen Ausführungsumgebung zu haben?
Dann habe ich jedoch angefangen, über den Zielmarkt von Dusk nachzudenken.
Wenn das Netzwerk darauf abzielt, regulierte Finanzanwendungen zu unterstützen, haben Settlement und Anwendungslogik nicht unbedingt dieselben Anforderungen. Die Schicht, die darüber entscheidet, worüber sich das Netzwerk einigt, benötigt möglicherweise andere Garantien als die Umgebung, in der Entwickler tatsächlich Anwendungen bauen.
Das macht die Architektur für mich noch interessanter.
Dusk versucht nicht nur, Smart Contracts privat zu machen. Es scheint, einige der Verantwortlichkeiten unterhalb der Verträge zu trennen.
Aber da ist noch etwas, das ich besser verstehen möchte.
Führt die Trennung von Settlement und Ausführung dazu, dass regulierte Anwendungen mehr Flexibilität bekommen, oder entsteht dadurch eine weitere Komplexität, mit der Entwickler sich schließlich auseinandersetzen müssen?
Das ist der Teil, in den ich als Nächstes tiefer eintauche.
$DUSK #dusk @Dusk