Ich bin heute immer wieder auf die Entwicklerseite von Dusk zurückgekommen, vor allem weil ich glaube, dass ich das Projekt zu sehr aus der Perspektive von Assets und Privatsphäre betrachtet habe.
Der Teil, über den ich mich dabei am meisten gestolpert habe, war Rusk, die WebAssembly-basierte virtuelle Maschine von Dusk. Was mich dabei besonders angesprochen hat, ist nicht nur, dass es sich um noch eine weitere Ausführungsebene handelt. Das Whitepaper beschreibt eine native Unterstützung für die Verifikation von Zero-Knowledge-Proofs und eine effiziente Merkle-Tree-Erstellung innerhalb der VM. Das klingt nach einer kleinen Implementierungs-Detailfrage, bis ich darüber nachdenke, was das für Entwickler bedeuten könnte, die Anwendungen bauen, bei denen das Nachweisen von etwas ohne Preisgabe von allem tatsächlich Teil des Problems ist.
Ich versuche aber immer noch zu entscheiden, wie viel davon außerhalb des technischen Designs überhaupt relevant ist. Kryptografie mangelt es nicht an Infrastruktur, die beeindruckend klingt, wenn man die Architektur liest, und sich dann viel weniger wichtig anfühlt, wenn man nach Leuten sucht, die sie tatsächlich bauen und verwenden.
Vielleicht ist das auch der Grund, warum ich mich mehr für die Entwicklererfahrung interessiere als für die Feature-Liste. Wenn die kryptografischen Werkzeuge in die Ausführungsumgebung eingebaut sind, macht das dann wirklich das Erstellen privater Anwendungen leichter – oder verlagert sich die Komplexität nur an einen anderen Ort?
Und da ist noch etwas, das ich im Blick behalten möchte: Ob Entwickler, die das EVM-Ökosystem bereits kennen, genug Gründe finden, mit Dusk zu experimentieren, anstatt dort zu bleiben, wo Tools und Nutzer schon vorhanden sind.
Mich interessiert, welche Seite in der Praxis gewinnt: besseres natives Werkzeug für Privatsphäre oder die Bequemlichkeit eines bereits etablierten Entwickler-Ökosystems?
@Dusk_Foundation $DUSK #dusk
Der Teil, über den ich mich dabei am meisten gestolpert habe, war Rusk, die WebAssembly-basierte virtuelle Maschine von Dusk. Was mich dabei besonders angesprochen hat, ist nicht nur, dass es sich um noch eine weitere Ausführungsebene handelt. Das Whitepaper beschreibt eine native Unterstützung für die Verifikation von Zero-Knowledge-Proofs und eine effiziente Merkle-Tree-Erstellung innerhalb der VM. Das klingt nach einer kleinen Implementierungs-Detailfrage, bis ich darüber nachdenke, was das für Entwickler bedeuten könnte, die Anwendungen bauen, bei denen das Nachweisen von etwas ohne Preisgabe von allem tatsächlich Teil des Problems ist.
Ich versuche aber immer noch zu entscheiden, wie viel davon außerhalb des technischen Designs überhaupt relevant ist. Kryptografie mangelt es nicht an Infrastruktur, die beeindruckend klingt, wenn man die Architektur liest, und sich dann viel weniger wichtig anfühlt, wenn man nach Leuten sucht, die sie tatsächlich bauen und verwenden.
Vielleicht ist das auch der Grund, warum ich mich mehr für die Entwicklererfahrung interessiere als für die Feature-Liste. Wenn die kryptografischen Werkzeuge in die Ausführungsumgebung eingebaut sind, macht das dann wirklich das Erstellen privater Anwendungen leichter – oder verlagert sich die Komplexität nur an einen anderen Ort?
Und da ist noch etwas, das ich im Blick behalten möchte: Ob Entwickler, die das EVM-Ökosystem bereits kennen, genug Gründe finden, mit Dusk zu experimentieren, anstatt dort zu bleiben, wo Tools und Nutzer schon vorhanden sind.
Mich interessiert, welche Seite in der Praxis gewinnt: besseres natives Werkzeug für Privatsphäre oder die Bequemlichkeit eines bereits etablierten Entwickler-Ökosystems?
@Dusk_Foundation $DUSK #dusk