Etwas, worauf ich während der Arbeit an der DuskEVM-Testnet-Activity in der vergangenen Woche immer wieder zurückkam — insbesondere bei den Vertragsinteraktionen, die nach der Beilegung der Bridge-Situation vom 16. August live gingen — ist, wie unterschiedlich Dusk Network ($DUSK ) mit Identität versus Autorisierung umgeht. #dusk @Dusk
Die meisten Onchain-Identitätsprojekte vermischen beides. Man weist nach, wer man ist, und dieser Nachweis wird zur eigenen Erlaubnis. Fertig. Aber in der Architektur von Dusk sind Identität und Autorisierung getrennte Ebenen. Citadel übernimmt die Identitätsbestätigung über ZK-KYC — du weist Attribute nach, ohne sie offenzulegen. Doch die eigentliche Frage, wozu du mit einem bestimmten Asset autorisiert bist, ist eine andere und wird separat geregelt. Das regulierte Asset selbst trägt die Autorisierungslogik, nicht das Identitätszertifikat.
Hmm. Diese Trennung ist wichtiger, als es klingt. In TradFi macht dich die Kenntnis darüber, wer du bist, nicht automatisch für jedes Instrument frei. Eine verifizierte institutionelle Wallet und eine verifizierte Retail-Wallet sind keine fungiblen Gegenparteien für eine Anleiheemission. Dusk scheint diese Unterscheidung auf Protokollebene abzubilden, statt sie in die Anwendungsebene hochzuschieben.
Ich bin ehrlich: Ich habe fast darüber hinweggeglänzt. Ich habe den Großteil der Session auf die Struktur des ZK-Proofs konzentriert, bis die Trennung der Autorisierung klickte.
Trotzdem ist noch nicht klar, wie granular diese Autorisierungslogik tatsächlich sein kann, bevor es zu teuer wird oder zu spröde, um sie über verschiedene Asset-Typen hinweg wartbar zu halten.
Die meisten Onchain-Identitätsprojekte vermischen beides. Man weist nach, wer man ist, und dieser Nachweis wird zur eigenen Erlaubnis. Fertig. Aber in der Architektur von Dusk sind Identität und Autorisierung getrennte Ebenen. Citadel übernimmt die Identitätsbestätigung über ZK-KYC — du weist Attribute nach, ohne sie offenzulegen. Doch die eigentliche Frage, wozu du mit einem bestimmten Asset autorisiert bist, ist eine andere und wird separat geregelt. Das regulierte Asset selbst trägt die Autorisierungslogik, nicht das Identitätszertifikat.
Hmm. Diese Trennung ist wichtiger, als es klingt. In TradFi macht dich die Kenntnis darüber, wer du bist, nicht automatisch für jedes Instrument frei. Eine verifizierte institutionelle Wallet und eine verifizierte Retail-Wallet sind keine fungiblen Gegenparteien für eine Anleiheemission. Dusk scheint diese Unterscheidung auf Protokollebene abzubilden, statt sie in die Anwendungsebene hochzuschieben.
Ich bin ehrlich: Ich habe fast darüber hinweggeglänzt. Ich habe den Großteil der Session auf die Struktur des ZK-Proofs konzentriert, bis die Trennung der Autorisierung klickte.
Trotzdem ist noch nicht klar, wie granular diese Autorisierungslogik tatsächlich sein kann, bevor es zu teuer wird oder zu spröde, um sie über verschiedene Asset-Typen hinweg wartbar zu halten.
