#dusk $DUSK Gestern Abend habe ich in dem Update-Log der Dusk-Offiziellen Seite zum AEGIS-Sicherheitsrahmen nachgelesen und ein Modul entdeckt, das von den meisten übersehen wird: Hedger. Seine Aufgabe besteht darin, bei der Ausführung von XSC-Verträgen sensible Daten (Positionsgröße, Handelsbetrag, Identität der Gegenpartei) nach einer ZK-Verschlüsselung on-chain abzulegen, sodass nur Adressen mit dem entsprechenden view key sie entschlüsseln können. Was bedeutet das? Dass bei Wertpapiertransaktionen auf der Dusk-Chain die On-Chain-Daten verschlüsselt sind, Regulierungs- und Audit-Instanzen aber jederzeit entschlüsseln und prüfen können.$SPCXB
Das unterscheidet sich komplett von der Logik von Tornado Cash „bei allen wird gemischt, niemand sieht etwas“. Das Problem bei Tornado ist, dass die Regulierung vollkommen blind ist, OFAC sanktioniert direkt. Dusk’ Hedger ist „Standardverschlüsselung, selektive Offenlegung“: Die Aufsichtsinstanz, die den view key besitzt, kann sehen, während normale Knoten das nicht sehen können, und die Gegenpartei sieht nur den für sie relevanten Ausschnitt. Das trifft genau den Balancepunkt zwischen den von MiCA geforderten „Datenschutz“-Anforderungen und „Anti-Geldwäsche“.$SNDKB
Noch interessanter ist das Audit-Modul von AEGIS: NPEX als MTF kann einen genehmigenden Delegierten-Knoten betreiben. Bei jeder Überweisung, die tokenisierte Wertpapiere betrifft, verifiziert der genehmigende Delegierten-Knoten auf der Konsens-Ebene die Compliance-Tags, die von Hedger annotiert wurden. Nicht-konforme Überweisungen werden bereits in der SBA-Abstimmungsphase abgelehnt und kommen gar nicht erst on-chain. Das ist eine ganze Ebene mehr als „nachträgliche Prüfung“: Compliance ist Teil des Konsenses, nicht ein nachträglich von einer Compliance-Abteilung nachgeliefertes Berichtswesen.
Ich dachte zuvor, Dusk’ Privatsphäre sei einfach „ein ZK draufsetzen“. Aber nachdem ich die AEGIS-Architektur durchgesehen habe, wurde mir klar: Es handelt sich um einen ganzen Protokoll-Stack aus „Privatsphäre + Compliance“. Was denkt ihr: Ist der Ausweg für Privacy-Chains vollständige Anonymität oder selektive Offenlegung?
#dusk @Dusk
Das unterscheidet sich komplett von der Logik von Tornado Cash „bei allen wird gemischt, niemand sieht etwas“. Das Problem bei Tornado ist, dass die Regulierung vollkommen blind ist, OFAC sanktioniert direkt. Dusk’ Hedger ist „Standardverschlüsselung, selektive Offenlegung“: Die Aufsichtsinstanz, die den view key besitzt, kann sehen, während normale Knoten das nicht sehen können, und die Gegenpartei sieht nur den für sie relevanten Ausschnitt. Das trifft genau den Balancepunkt zwischen den von MiCA geforderten „Datenschutz“-Anforderungen und „Anti-Geldwäsche“.$SNDKB
Noch interessanter ist das Audit-Modul von AEGIS: NPEX als MTF kann einen genehmigenden Delegierten-Knoten betreiben. Bei jeder Überweisung, die tokenisierte Wertpapiere betrifft, verifiziert der genehmigende Delegierten-Knoten auf der Konsens-Ebene die Compliance-Tags, die von Hedger annotiert wurden. Nicht-konforme Überweisungen werden bereits in der SBA-Abstimmungsphase abgelehnt und kommen gar nicht erst on-chain. Das ist eine ganze Ebene mehr als „nachträgliche Prüfung“: Compliance ist Teil des Konsenses, nicht ein nachträglich von einer Compliance-Abteilung nachgeliefertes Berichtswesen.
Ich dachte zuvor, Dusk’ Privatsphäre sei einfach „ein ZK draufsetzen“. Aber nachdem ich die AEGIS-Architektur durchgesehen habe, wurde mir klar: Es handelt sich um einen ganzen Protokoll-Stack aus „Privatsphäre + Compliance“. Was denkt ihr: Ist der Ausweg für Privacy-Chains vollständige Anonymität oder selektive Offenlegung?
#dusk @Dusk
彻底匿名才是真正的隐私
0%
监管会自己适应新技术
100%
1 Stimmen • Abstimmung beendet