#dusk $DUSK Heute versuche ich, die Technik-Architektur von Dusk mit ganz normaler Sprache durchzugehen—möglichst ohne eine ganze Menge Fachjargon. Vielleicht verstehen auch Leute ohne Technik-Vorkenntnisse zumindest grob, worum es geht.
Zuerst das Fazit: @Dusk Das komplette System ist im Kern eine „Zwei-Etagen“-Struktur: Eine Etage kümmert sich um Privatsphäre, die andere um Compliance—jede Schicht macht ihre Aufgabe.$AKE
Erste Etage: Phoenix, zuständig für Privatsphäre.
Es basiert auf einer UTXO-Architektur (ganz einfach: „jede einzelne Münze ist wie ein eigenes, unabhängiges Stück“, statt „ein einziges Gesamtkonto“). Die Zero-Knowledge-Beweise sind direkt in die Transaktionsebene eingebaut. Beim Überweisen sind Infos wie deine Adresse und der Betrag auf der Kette verschlüsselt—wer die Blockchain abscannt, sieht keinen Klartext. Gleichzeitig kann das Netzwerk aber trotzdem prüfen, dass die Transaktion gültig ist (keine Doppel-Ausgabe, kein Überschreiten). So löst es das alte Problem „Privatsphäre ja, aber ohne die Verifizierbarkeit zu verlieren“.
Zweite Etage: Zedger, zuständig für Compliance.
Wenn Phoenix „Details verstecken“ ist, dann ist Zedger „Regeln einhalten“. Es ist speziell für tokenisierte Wertpapiere (Securities Tokens) gedacht und bringt Compliance-Regeln direkt als Logik in die Kette. Zum Beispiel: Wenn ein bestimmter Security-Token festlegt, dass ein einzelner Inhaber nicht mehr als 5% des Gesamts halten darf, dann wird eine Überweisung, die diesen Grenzwert überschreitet, on-chain direkt abgelehnt—ohne dass man dafür auf eine manuelle Prüfung außerhalb der Kette angewiesen ist. Auch typische Regeln aus dem klassischen Finanzbereich wie Haltlimits, Whitelists und Sperrfristen lassen sich durch Zedger automatisieren.
Darunter die Basis: DuskDS + DuskEVM + DuskVM.$SPCXB
DuskDS ist die Konsens-Schicht und sorgt für deterministisches Finalisieren: Sobald eine Transaktion auf der Kette ist, ist sie der endgültige Zustand—im Gegensatz zu PoW-Chainen, die manchmal noch Reorgs haben können. DuskEVM ist kompatibel mit Solidity, damit Entwickler aus dem Ethereum-Ökosystem kostengünstig migrieren können. DuskVM bewahrt die nativen Fähigkeiten für Privacy-Computing—für Szenarien, die eine noch stärkere Individualisierung brauchen.
Das Schlaue an diesem Design ist, dass es „Privatsphäre“ und „Compliance“ nicht als Gegensätze behandelt. Stattdessen werden die Anforderungen über Schichten getrennt: Jede Seite löst sie mit der jeweils passendsten Methode, und am Ende fügt man beides zusammen. Genau deshalb traut sich Dusk, auf RWA und regulatorisch konformes Finance zu setzen—weil der Tech-Stack von Anfang an für genau diesen Use Case gebaut wurde, nicht „draufgeklebt“.
Wenn man die Grundidee einmal sortiert hat, sieht man auch bei Positionierung und Partnern (AFM, die Gruppe rund um NPE Exchange), dass die ganze Linie stimmig ist—kein zusammengebasteltes Märchen.
#dusk @Dusk
Zuerst das Fazit: @Dusk Das komplette System ist im Kern eine „Zwei-Etagen“-Struktur: Eine Etage kümmert sich um Privatsphäre, die andere um Compliance—jede Schicht macht ihre Aufgabe.$AKE
Erste Etage: Phoenix, zuständig für Privatsphäre.
Es basiert auf einer UTXO-Architektur (ganz einfach: „jede einzelne Münze ist wie ein eigenes, unabhängiges Stück“, statt „ein einziges Gesamtkonto“). Die Zero-Knowledge-Beweise sind direkt in die Transaktionsebene eingebaut. Beim Überweisen sind Infos wie deine Adresse und der Betrag auf der Kette verschlüsselt—wer die Blockchain abscannt, sieht keinen Klartext. Gleichzeitig kann das Netzwerk aber trotzdem prüfen, dass die Transaktion gültig ist (keine Doppel-Ausgabe, kein Überschreiten). So löst es das alte Problem „Privatsphäre ja, aber ohne die Verifizierbarkeit zu verlieren“.
Zweite Etage: Zedger, zuständig für Compliance.
Wenn Phoenix „Details verstecken“ ist, dann ist Zedger „Regeln einhalten“. Es ist speziell für tokenisierte Wertpapiere (Securities Tokens) gedacht und bringt Compliance-Regeln direkt als Logik in die Kette. Zum Beispiel: Wenn ein bestimmter Security-Token festlegt, dass ein einzelner Inhaber nicht mehr als 5% des Gesamts halten darf, dann wird eine Überweisung, die diesen Grenzwert überschreitet, on-chain direkt abgelehnt—ohne dass man dafür auf eine manuelle Prüfung außerhalb der Kette angewiesen ist. Auch typische Regeln aus dem klassischen Finanzbereich wie Haltlimits, Whitelists und Sperrfristen lassen sich durch Zedger automatisieren.
Darunter die Basis: DuskDS + DuskEVM + DuskVM.$SPCXB
DuskDS ist die Konsens-Schicht und sorgt für deterministisches Finalisieren: Sobald eine Transaktion auf der Kette ist, ist sie der endgültige Zustand—im Gegensatz zu PoW-Chainen, die manchmal noch Reorgs haben können. DuskEVM ist kompatibel mit Solidity, damit Entwickler aus dem Ethereum-Ökosystem kostengünstig migrieren können. DuskVM bewahrt die nativen Fähigkeiten für Privacy-Computing—für Szenarien, die eine noch stärkere Individualisierung brauchen.
Das Schlaue an diesem Design ist, dass es „Privatsphäre“ und „Compliance“ nicht als Gegensätze behandelt. Stattdessen werden die Anforderungen über Schichten getrennt: Jede Seite löst sie mit der jeweils passendsten Methode, und am Ende fügt man beides zusammen. Genau deshalb traut sich Dusk, auf RWA und regulatorisch konformes Finance zu setzen—weil der Tech-Stack von Anfang an für genau diesen Use Case gebaut wurde, nicht „draufgeklebt“.
Wenn man die Grundidee einmal sortiert hat, sieht man auch bei Positionierung und Partnern (AFM, die Gruppe rund um NPE Exchange), dass die ganze Linie stimmig ist—kein zusammengebasteltes Märchen.
#dusk @Dusk
ZK证明到底是什么原理
0%
UTXO和账户模型哪个好
100%
兼容EVM有多重要
0%
1 Stimmen • Abstimmung beendet