Ich habe heute etwas Zeit damit verbracht nachzuverfolgen, wie Dusk sich von privaten Transaktionen hin zu tatsächlichen Finanzanwendungen bewegt, und mir ist aufgefallen, wie viele Schichten zusammenarbeiten müssen.
Phoenix hat zuerst meine Aufmerksamkeit erregt. Statt den Transaktionsdetails dem Netzwerk zur direkten Prüfung offenzulegen, fordert es das Netzwerk auf, einen Zero-Knowledge-Beweis zu verifizieren. Das klingt elegant, aber es ließ mich auch fragen: Wie viel Sicherheit hängt letztlich von der Korrektheit des Beweissystems und seiner Implementierung ab?
Dann bin ich auf Viewing Keys gestoßen. Wenn jemand das Scannen von Transaktionen delegieren kann, ohne dabei Ausgabebefugnisse preiszugeben, könnte das für regulierte Institutionen nützlich werden, die eine kontrollierte Sicht benötigen? Aber wer sollte diese Berechtigungen zur Ansicht kontrollieren, und was passiert, wenn sie kompromittiert werden?
Die WASM-basierte Piecrust-VM stellte eine andere Frage. Warum nutzt man WASM auf der Ausführungsebene, während man umfangreiche kryptografische Operationen in native Host-Funktionen verlagert? Meine Interpretation ist, dass Dusk versucht, Smart Contracts portierbar zu halten und gleichzeitig unnötigen Rechenaufwand zu vermeiden, aber hier wird die Sicherheitsgrenze besonders wichtig.
Genesis-Contracts scheinen außerdem bedeutsamer zu sein, als ich zunächst angenommen hatte. Sie übernehmen grundlegende Funktionen wie Transfers und Staking, daher könnten Fehler dort netzwerkweite Folgen haben.
Zedger hat das gesamte Design wieder in Richtung Finanzen zurückgebracht. Wenn Wertpapiere und RWAs Privatsphäre, Nachvollziehbarkeit und Aktionen wie Dividenden oder Zwangstransfers benötigen, kann ein einziges System all diese Anforderungen erfüllen, ohne dabei neue Governance-Risiken zu schaffen?
Ich denke immer noch darüber nach, wo genau die realen Vertrauensannahmen liegen.
@Dusk_Foundation #dusk $DUSK
Phoenix hat zuerst meine Aufmerksamkeit erregt. Statt den Transaktionsdetails dem Netzwerk zur direkten Prüfung offenzulegen, fordert es das Netzwerk auf, einen Zero-Knowledge-Beweis zu verifizieren. Das klingt elegant, aber es ließ mich auch fragen: Wie viel Sicherheit hängt letztlich von der Korrektheit des Beweissystems und seiner Implementierung ab?
Dann bin ich auf Viewing Keys gestoßen. Wenn jemand das Scannen von Transaktionen delegieren kann, ohne dabei Ausgabebefugnisse preiszugeben, könnte das für regulierte Institutionen nützlich werden, die eine kontrollierte Sicht benötigen? Aber wer sollte diese Berechtigungen zur Ansicht kontrollieren, und was passiert, wenn sie kompromittiert werden?
Die WASM-basierte Piecrust-VM stellte eine andere Frage. Warum nutzt man WASM auf der Ausführungsebene, während man umfangreiche kryptografische Operationen in native Host-Funktionen verlagert? Meine Interpretation ist, dass Dusk versucht, Smart Contracts portierbar zu halten und gleichzeitig unnötigen Rechenaufwand zu vermeiden, aber hier wird die Sicherheitsgrenze besonders wichtig.
Genesis-Contracts scheinen außerdem bedeutsamer zu sein, als ich zunächst angenommen hatte. Sie übernehmen grundlegende Funktionen wie Transfers und Staking, daher könnten Fehler dort netzwerkweite Folgen haben.
Zedger hat das gesamte Design wieder in Richtung Finanzen zurückgebracht. Wenn Wertpapiere und RWAs Privatsphäre, Nachvollziehbarkeit und Aktionen wie Dividenden oder Zwangstransfers benötigen, kann ein einziges System all diese Anforderungen erfüllen, ohne dabei neue Governance-Risiken zu schaffen?
Ich denke immer noch darüber nach, wo genau die realen Vertrauensannahmen liegen.
@Dusk_Foundation #dusk $DUSK