Ich habe mich selbst hingesetzt und das neue EVM-Testnet von Dusk ausprobiert – und bin mit mehr Fragen als Antworten wieder aufgestanden. Seltsamerweise sehe ich das als gutes Zeichen.

Wenn ich ein Privacy-Projekt zu schnell verstehe, gehe ich normalerweise davon aus, dass mir etwas entgangen ist.

Ich bin mit der Erwartung gestartet, dass Privacy ein natürlicher Bestandteil von Dusk sein würde.

Stattdessen war alles viel zu… normal.

Chain ID 745, Hardhat lief reibungslos an, Blockscout verifiziert. Vertraute L2-Ausführung, Datenverfügbarkeit bei DuskDS veröffentlicht.

Keine Standardverschlüsselung. Keine verschleierten Transaktionen. Keine Standard-Privacy.

Je mehr ich hinsah, desto klarer wurde mir: Das Problem liegt darin, dass etwas, das noch nicht zum Default geworden ist.

Ich fragte mich immer wieder: „Wenn Privacy grundlegend ist, warum ist sie dann nicht die Standardeinstellung?“

Vielleicht ist das die falsche Frage.

Dusk hat aktuell zwei Türen.

Die eine ist weit offen: Ethereum-Kompatibilität, vertraute Tools, null Reibung.

Die andere ist Privacy – die immer noch einen separaten Adresstyp, ein SDK und ein entsprechendes Denkmodell voraussetzt. Sie ist weiterhin Opt-in.

Wenn Privacy optional wird statt die Standardeinstellung – wie viel Substanz bleibt dann in „compliant by design“?

Ist es ein Kern-Design oder nur eine Schicht, die hinzukommt, wenn sie gebraucht wird?

Ich habe die Antwort noch nicht.

Ich mache Dusk keinen Vorwurf, dass es zuerst EVM priorisiert. Aber mir ist mehr daran gelegen, wie groß die Lücke zwischen dem ist, was läuft, und dem, was noch auf der Roadmap steht.

Dort sind oft die wichtigsten Details verborgen.

Als Nächstes möchte ich tiefer in Dusk’ Privacy-Architektur eintauchen.

Ich habe das Gefühl, dass dort mein aktuelles Verständnis entweder bestätigt wird – oder sich komplett verändert.
@Dusk_Foundation #dusk $DUSK $KII $AEON
#BNBChainToActivatePasteurHardFork #SanDiskRises7%OnRevenueGrowthOutlook #USJulyRetailSalesFall0.6% #SaudiPIFDiscloses154.1MSpaceXShares