@Dusk $DUSK #dusk
Ich habe mir die Dusk-Dokumentation angesehen, und eine Sache hat mich immer wieder zurückgezogen.
Zunächst dachte ich, der interessante Teil sei einfach, dass sie versucht, Privatsphäre in Finanzanwendungen zu bringen. Aber je tiefer ich in die Architektur eingedrungen bin, desto weniger „Privacy-Blockchain“ fühlte sich wie eine vollständige Beschreibung an.
Dusk hat verschiedene Komponenten, die unterschiedliche Arten von Aktivitäten übernehmen. Moonlight ist für die vertrautere kontobasierte Seite da, Phoenix für geschützte UTXO-Transaktionen und das XSC-/Hedger-Design für Dinge wie regulierte Assets und finanzielle Regeln.
Das hat mich kurz stoppen lassen.
Denn bei Finanz-Assets ist das Verbergen einer Transaktion nur ein Teil des Problems.
Man braucht möglicherweise auch Regeln dazu, wer etwas halten darf, wer es übertragen kann, welche Informationen eine andere Partei sehen darf oder ob eine bestimmte Übertragung überhaupt gültig ist.
In den Dokumenten geht es um Themen wie selektive Offenlegung, Identitätsnachweise (Identity Credentials) und Einschränkungen auf Asset-Ebene. Das lässt das Privatsphäre-Modell weniger wie „Mache alles unsichtbar“ wirken, sondern eher wie „Gib nur das preis, was die Anwendung tatsächlich offenlegen muss“.
Ich glaube, diese Unterscheidung ist leicht zu übersehen.
Ein weiterer interessanter Punkt, den ich gefunden habe, ist, dass Dusk sowohl DuskVM als auch DuskEVM hat. Die native VM gibt Contracts Zugriff auf die eigenen Privatsphäre- und ZK-Fähigkeiten von Dusk, während die EVM-Seite dafür gedacht ist, Solidity/Vyper sowie vertraute Tools möglich zu machen.
Jetzt frage ich mich also etwas anderes.
Wenn eine Anwendung irgendwann die Flexibilität der EVM-Entwicklung braucht, aber gleichzeitig stark auf die nativen Privatsphäre-Funktionen von Dusk angewiesen ist: Wo wird diese Grenze in der Praxis spürbar?
Die Dokumentation zeichnet ziemlich klar nach, warum es beide Wege gibt.
Mich interessiert eher, wie sich das Bauen über diese Grenze hinweg tatsächlich anfühlt.
Ich habe mir die Dusk-Dokumentation angesehen, und eine Sache hat mich immer wieder zurückgezogen.
Zunächst dachte ich, der interessante Teil sei einfach, dass sie versucht, Privatsphäre in Finanzanwendungen zu bringen. Aber je tiefer ich in die Architektur eingedrungen bin, desto weniger „Privacy-Blockchain“ fühlte sich wie eine vollständige Beschreibung an.
Dusk hat verschiedene Komponenten, die unterschiedliche Arten von Aktivitäten übernehmen. Moonlight ist für die vertrautere kontobasierte Seite da, Phoenix für geschützte UTXO-Transaktionen und das XSC-/Hedger-Design für Dinge wie regulierte Assets und finanzielle Regeln.
Das hat mich kurz stoppen lassen.
Denn bei Finanz-Assets ist das Verbergen einer Transaktion nur ein Teil des Problems.
Man braucht möglicherweise auch Regeln dazu, wer etwas halten darf, wer es übertragen kann, welche Informationen eine andere Partei sehen darf oder ob eine bestimmte Übertragung überhaupt gültig ist.
In den Dokumenten geht es um Themen wie selektive Offenlegung, Identitätsnachweise (Identity Credentials) und Einschränkungen auf Asset-Ebene. Das lässt das Privatsphäre-Modell weniger wie „Mache alles unsichtbar“ wirken, sondern eher wie „Gib nur das preis, was die Anwendung tatsächlich offenlegen muss“.
Ich glaube, diese Unterscheidung ist leicht zu übersehen.
Ein weiterer interessanter Punkt, den ich gefunden habe, ist, dass Dusk sowohl DuskVM als auch DuskEVM hat. Die native VM gibt Contracts Zugriff auf die eigenen Privatsphäre- und ZK-Fähigkeiten von Dusk, während die EVM-Seite dafür gedacht ist, Solidity/Vyper sowie vertraute Tools möglich zu machen.
Jetzt frage ich mich also etwas anderes.
Wenn eine Anwendung irgendwann die Flexibilität der EVM-Entwicklung braucht, aber gleichzeitig stark auf die nativen Privatsphäre-Funktionen von Dusk angewiesen ist: Wo wird diese Grenze in der Praxis spürbar?
Die Dokumentation zeichnet ziemlich klar nach, warum es beide Wege gibt.
Mich interessiert eher, wie sich das Bauen über diese Grenze hinweg tatsächlich anfühlt.
