Ich habe etwas bemerkt, als ich Fragen ausprobiert habe: Wenn Privacy auf dem EVM-Testnet von Dusk nur „zusätzliches Tooling, wenn es sich anbietet“ ist, was würde dann einen Entwickler wirklich dazu bringen, es zu nutzen statt es einfach zu ignorieren.
Für die meisten Entwickler gewinnt standardmäßig immer die Standardeinstellung – nicht, weil sie Funktionen mit Mehrwert nicht mögen, sondern weil die Defaults der geringste Widerstand sind, wenn man gerade dabei ist, das Produkt innerhalb des Deadlines fertigzustellen. Eine Funktion, die in einer eigenen Doku steckt, eigenes SDK-Lernen erfordert und ein anderes Denkmodell verlangt als das vertraute EVM, wird immer nach unten in die Liste „später“ geschoben, außer es gibt einen wirklich zwingenden Grund, sie sofort priorisieren zu müssen.
Das ist eher ein Verhaltens- als ein technisches Problem. Egal wie stark Hedger-Mechanismen oder die symmetrische Chiffrierung im Code @Dusk m auch im Design wirken: Wenn der Default-Weg weiterhin eine standardmäßige OP-Stack-Kette ohne Verschlüsselung ist, werden die meisten Anwendungen, die in dieser frühen Phase auf diesem Testnet aufgebaut werden, sehr wahrscheinlich diese Privacy-Schicht nicht nutzen – einfach, weil niemand dazu gezwungen ist, sie zu verwenden. Wenn sich das bis zum Mainnet fortsetzt, könnte das zur Folge haben, dass eine App-Ökologie weitgehend nicht den Kernnutzen ausschöpft, für den $DUSK entwickelt wurde.
Selbst-Widerspruch: Vielleicht ist das auch nur eine zu frühe Sorge – Testnets priorisieren immer zuerst das Einfachere, und Privacy könnte in der Mainnet-Phase zum Default werden, wenn Dusk genügend Zeit hatte, die Dev-Experience dafür zu verfeinern.
Ich warte darauf zu sehen, ob Dusk einen konkreten Fahrplan veröffentlicht, um Privacy von „zusätzlichem Tooling“ hin zu etwas zu bringen, das näher an einem Default liegt, bevor sich die App-Ökologie in die entgegengesetzte Richtung formt.
#dusk $AKE $BTC
Für die meisten Entwickler gewinnt standardmäßig immer die Standardeinstellung – nicht, weil sie Funktionen mit Mehrwert nicht mögen, sondern weil die Defaults der geringste Widerstand sind, wenn man gerade dabei ist, das Produkt innerhalb des Deadlines fertigzustellen. Eine Funktion, die in einer eigenen Doku steckt, eigenes SDK-Lernen erfordert und ein anderes Denkmodell verlangt als das vertraute EVM, wird immer nach unten in die Liste „später“ geschoben, außer es gibt einen wirklich zwingenden Grund, sie sofort priorisieren zu müssen.
Das ist eher ein Verhaltens- als ein technisches Problem. Egal wie stark Hedger-Mechanismen oder die symmetrische Chiffrierung im Code @Dusk m auch im Design wirken: Wenn der Default-Weg weiterhin eine standardmäßige OP-Stack-Kette ohne Verschlüsselung ist, werden die meisten Anwendungen, die in dieser frühen Phase auf diesem Testnet aufgebaut werden, sehr wahrscheinlich diese Privacy-Schicht nicht nutzen – einfach, weil niemand dazu gezwungen ist, sie zu verwenden. Wenn sich das bis zum Mainnet fortsetzt, könnte das zur Folge haben, dass eine App-Ökologie weitgehend nicht den Kernnutzen ausschöpft, für den $DUSK entwickelt wurde.
Selbst-Widerspruch: Vielleicht ist das auch nur eine zu frühe Sorge – Testnets priorisieren immer zuerst das Einfachere, und Privacy könnte in der Mainnet-Phase zum Default werden, wenn Dusk genügend Zeit hatte, die Dev-Experience dafür zu verfeinern.
Ich warte darauf zu sehen, ob Dusk einen konkreten Fahrplan veröffentlicht, um Privacy von „zusätzlichem Tooling“ hin zu etwas zu bringen, das näher an einem Default liegt, bevor sich die App-Ökologie in die entgegengesetzte Richtung formt.
#dusk $AKE $BTC
