#dusk $DUSK Hier ist etwas, das in den meisten DUSK-Erklärungen übersehen wird: Das ist keine Kette mit nur einem angehängten Datenschutzmodell. Es ist eine Kette, die zwei unterschiedliche Transaktionsmodelle gleichzeitig ausführt – weil eine Zahlung und eine Sicherheit nicht dieselbe Art von Objekt sind und nicht auf dieselbe Weise scheitern.
Phoenix ist das UTxO-artige Modell für alltägliche verschleierte Überweisungen: Guthaben und Gegenparteien sind verborgen, Notizen werden in einem Merkle-Tree nachverfolgt, Nullifier verhindern Doppelausgaben, ohne offenzulegen, welche Notiz ausgegeben wurde. Es ist für Durchsatz und Vertraulichkeit bei normalen Werttransfers gebaut.
Zedger ist aus Absicht anders. Es ist speziell für tokenisierte Wertpapiere modelliert – wobei der Sinn nicht nur darin besteht, ein Guthaben zu verbergen: Es geht darum, nachzuweisen, dass Lebenszyklusereignisse (Emission, Übertragungsbeschränkungen, gesellschaftsrechtliche Maßnahmen, Rücknahme) korrekt innerhalb eines regulatorischen Rahmens stattgefunden haben, ohne die Cap-Table der öffentlichen Kette offenzulegen. Ein Sicherheitstoken hat Pflichten, für die Phoenix nie ausgelegt war: Übertragungsbeschränkungen, die an den Investorstatus gekoppelt sind; die Möglichkeit für den Emittenten, unter bestimmten rechtlichen Bedingungen einzufrieren oder zurückzufordern; sowie Audit-Anforderungen, die selbst dann bestehen bleiben, wenn die Guthaben versiegelt bleiben.
Beides auf einer einzigen Settlement-Layer laufen zu lassen, ist die eigentliche Engineering-Wette. Dusk entscheidet sich nicht zwischen „private Payments-Chain“ und „compliant Securities-Chain“ – Dusk argumentiert, dass man beide Bausteine im selben Ausführungsumfeld braucht, weil ein regulierter Markt beide Arten von Transaktionen am selben Handelstag berührt. Der Transfer-Contract steuert beide Flüsse über dasselbe Merkle-Tree-basierte Integritätsmodell – eine sauberere Architektur, als zwei Ketten mit zwei unterschiedlichen Datenschutzgarantien zu überbrücken.
Die offene Frage ist, ob diese Dual-Model-Komplexität zu einer Wartungsbelastung wird, während sich beide Spezifikationen unabhängig weiterentwickeln, oder ob sie tatsächlich robuster ist als eine „one-size-fits-all“-Datenschutzschicht.
Weiß jemand von einem anderen L1, das bewusst zwei getrennte Produktions-Transaktionsmodelle nach Aufteilung nach Asset-Klasse ausliefert – statt eine generische Datenschutz-Primitive über alles zu stülpen?
@Dusk $NVDAB
Phoenix ist das UTxO-artige Modell für alltägliche verschleierte Überweisungen: Guthaben und Gegenparteien sind verborgen, Notizen werden in einem Merkle-Tree nachverfolgt, Nullifier verhindern Doppelausgaben, ohne offenzulegen, welche Notiz ausgegeben wurde. Es ist für Durchsatz und Vertraulichkeit bei normalen Werttransfers gebaut.
Zedger ist aus Absicht anders. Es ist speziell für tokenisierte Wertpapiere modelliert – wobei der Sinn nicht nur darin besteht, ein Guthaben zu verbergen: Es geht darum, nachzuweisen, dass Lebenszyklusereignisse (Emission, Übertragungsbeschränkungen, gesellschaftsrechtliche Maßnahmen, Rücknahme) korrekt innerhalb eines regulatorischen Rahmens stattgefunden haben, ohne die Cap-Table der öffentlichen Kette offenzulegen. Ein Sicherheitstoken hat Pflichten, für die Phoenix nie ausgelegt war: Übertragungsbeschränkungen, die an den Investorstatus gekoppelt sind; die Möglichkeit für den Emittenten, unter bestimmten rechtlichen Bedingungen einzufrieren oder zurückzufordern; sowie Audit-Anforderungen, die selbst dann bestehen bleiben, wenn die Guthaben versiegelt bleiben.
Beides auf einer einzigen Settlement-Layer laufen zu lassen, ist die eigentliche Engineering-Wette. Dusk entscheidet sich nicht zwischen „private Payments-Chain“ und „compliant Securities-Chain“ – Dusk argumentiert, dass man beide Bausteine im selben Ausführungsumfeld braucht, weil ein regulierter Markt beide Arten von Transaktionen am selben Handelstag berührt. Der Transfer-Contract steuert beide Flüsse über dasselbe Merkle-Tree-basierte Integritätsmodell – eine sauberere Architektur, als zwei Ketten mit zwei unterschiedlichen Datenschutzgarantien zu überbrücken.
Die offene Frage ist, ob diese Dual-Model-Komplexität zu einer Wartungsbelastung wird, während sich beide Spezifikationen unabhängig weiterentwickeln, oder ob sie tatsächlich robuster ist als eine „one-size-fits-all“-Datenschutzschicht.
Weiß jemand von einem anderen L1, das bewusst zwei getrennte Produktions-Transaktionsmodelle nach Aufteilung nach Asset-Klasse ausliefert – statt eine generische Datenschutz-Primitive über alles zu stülpen?
@Dusk $NVDAB