Die Datenschutz-Compliance-Chain ist drei Wochen gelaufen, doch Dusk hängt an der Toolchain – nicht am Konsens
Auf einem Testnetz habe ich einen Smart Contract mit einem geheimen Kontostand bereitgestellt. Die Kompilierungszeit des PlonK-Zircuits mit @Dusk war fast doppelt so lang wie erwartet. Nicht, dass es tödlich wäre – aber das Gefühl der Zersplitterung in der Toolchain ist ziemlich deutlich: Vom lokalen Node bis zur Signatur im Browser muss man oft manuell zwischen RPCs wechseln, und die Doku-Beispiele passen nicht zu den neuesten Versionen. Die Entwicklererfahrung bei Secret Network ist etwas reibungsloser, aber die TEE-Vertrauensannahmen seiner Lösung kann ich auf Dauer nicht so recht akzeptieren.
Dusk will den Weg über regulierte Finanzprodukte gehen, indem es Datenschutztransaktionen und Identitätsverifikation auf derselben Ebene verknüpft – die Richtung stimmt. In der Praxis zeigt sich jedoch: Das Generieren von Zero-Knowledge-Proofs ist selbst für normale Hardware noch stark rechenintensiv, und der Speicherverbrauch der Validierungs-Nodes ist ebenfalls nicht niedrig. Oasis hat in der Privacy-Layer modular aufgebaut – das macht die Entwicklung flexibel. Aber die On-Chain-Identitäts- und Compliance-Komponenten sitzen nicht so eng mit der Kette zusammen wie bei Dusk. In meinem Test für den Asset-Emissionsprozess ist Dusk mit seiner fein abgestuften Rechteverwaltung überzeugender: Es kann Emittenten, Audit-Nodes und normale Inhaber unterscheiden. Das ist in der Praxis greifbarer als eine Kette, die nur anonyme Transfers unterstützt.
Das Problem liegt aber auch hier: Dusk hebt die Entwickler-Hürde durch Compliance-Parameter. Viele Einstellungen erfordern, dass man regulatorische Fachbegriffe versteht, bevor man anfangen kann. Ein Cold-Start des Ökosystems könnte damit langsamer laufen als erwartet. $DUSK ist als Gebühren- und Governance-Logik klar, aber die aktuell auf der Kette bereitstellbaren Anwendungsarten sind noch relativ eng. Aleph Zero bietet allgemeinere Privacy-Contracts und der Gas-Verbrauch ist auch stabiler – allerdings fehlen ihm im Szenario regulierter Assets ein nativer Compliance-Framework.
Wenn Dusk das SDK etwas dünner kapseln und Compliance-Parameter als vordefinierte Vorlagen bereitstellen könnte, wäre die Entwicklererfahrung deutlich besser. Sonst wirkt es eher wie eine Kette, die für Institutionen maßgeschneidert ist – statt ein Ort, an dem normale Entwickler schnell Fehler ausprobieren können. Zumindest aus heutiger Sicht: Konsensfähigkeit ist gegeben; die Engpässe liegen bei Tooling und Dokumentation.
#dusk
Auf einem Testnetz habe ich einen Smart Contract mit einem geheimen Kontostand bereitgestellt. Die Kompilierungszeit des PlonK-Zircuits mit @Dusk war fast doppelt so lang wie erwartet. Nicht, dass es tödlich wäre – aber das Gefühl der Zersplitterung in der Toolchain ist ziemlich deutlich: Vom lokalen Node bis zur Signatur im Browser muss man oft manuell zwischen RPCs wechseln, und die Doku-Beispiele passen nicht zu den neuesten Versionen. Die Entwicklererfahrung bei Secret Network ist etwas reibungsloser, aber die TEE-Vertrauensannahmen seiner Lösung kann ich auf Dauer nicht so recht akzeptieren.
Dusk will den Weg über regulierte Finanzprodukte gehen, indem es Datenschutztransaktionen und Identitätsverifikation auf derselben Ebene verknüpft – die Richtung stimmt. In der Praxis zeigt sich jedoch: Das Generieren von Zero-Knowledge-Proofs ist selbst für normale Hardware noch stark rechenintensiv, und der Speicherverbrauch der Validierungs-Nodes ist ebenfalls nicht niedrig. Oasis hat in der Privacy-Layer modular aufgebaut – das macht die Entwicklung flexibel. Aber die On-Chain-Identitäts- und Compliance-Komponenten sitzen nicht so eng mit der Kette zusammen wie bei Dusk. In meinem Test für den Asset-Emissionsprozess ist Dusk mit seiner fein abgestuften Rechteverwaltung überzeugender: Es kann Emittenten, Audit-Nodes und normale Inhaber unterscheiden. Das ist in der Praxis greifbarer als eine Kette, die nur anonyme Transfers unterstützt.
Das Problem liegt aber auch hier: Dusk hebt die Entwickler-Hürde durch Compliance-Parameter. Viele Einstellungen erfordern, dass man regulatorische Fachbegriffe versteht, bevor man anfangen kann. Ein Cold-Start des Ökosystems könnte damit langsamer laufen als erwartet. $DUSK ist als Gebühren- und Governance-Logik klar, aber die aktuell auf der Kette bereitstellbaren Anwendungsarten sind noch relativ eng. Aleph Zero bietet allgemeinere Privacy-Contracts und der Gas-Verbrauch ist auch stabiler – allerdings fehlen ihm im Szenario regulierter Assets ein nativer Compliance-Framework.
Wenn Dusk das SDK etwas dünner kapseln und Compliance-Parameter als vordefinierte Vorlagen bereitstellen könnte, wäre die Entwicklererfahrung deutlich besser. Sonst wirkt es eher wie eine Kette, die für Institutionen maßgeschneidert ist – statt ein Ort, an dem normale Entwickler schnell Fehler ausprobieren können. Zumindest aus heutiger Sicht: Konsensfähigkeit ist gegeben; die Engpässe liegen bei Tooling und Dokumentation.
#dusk