@Dusk Ein Freund hat sich monatelang damit beschäftigt, ein Produkt als Marke eintragen zu lassen, bevor ihm klar wurde, dass der Name und der eigentliche Herstellungsprozess zwei völlig getrennte Registrierungen sind – ein Team kümmerte sich um die Marke, ein völlig anderes Team baute die Maschine, die das Produkt erst real machte. Ich ging davon aus, dass XSC und Zedger zwei konkurrierende Systeme auf Dusk seien. Diese Annahme zerfiel, als ich nachverfolgte, wie Dusk-eigene Architekturunterlagen die Beziehung beschreiben.
XSC, Confidential Security Contract, ist der Name der Funktionalität – der Standard von Dusk, der für sicherheitsbezogene Use-Cases verwendet wird. Zedger ist das konkrete hybride Transaktionsmodell, das UTXO- und kontobasierte Elemente kombiniert, und das Dusk-eigene Materialien als das Modell nennen, das die XSC-Funktionalität bereitstellt. Das eine benennt, was das Netzwerk kann. Das andere ist der Mechanismus, der es ausführt. $DUSK
Ab hier hört das auf, nur theoretisch zu sein. Eine Institution, die sich mit Dusk für die Tokenisierung von Wertpapieren integriert, trifft keine Entscheidung zwischen „XSC“ und „Zedger“ als konkurrierende Optionen – sie baut gezielt gegen Zedger, während XSC der Compliance-Standardname ist, auf den ihre rechtliche und regulatorische Dokumentation Bezug nehmen wird. Die beiden zu verwechseln bedeutet, dass ein Entwickler möglicherweise nach „XSC-Integration-Dokumentation“ sucht und übersieht, dass die tatsächliche technische Implementierung vollständig unter dem Namen von Zedger läuft. #dusk
Der eigentliche Test für DUSK ist, ob diese Namensaufteilung jemals dazu führt, dass eine Institution eine Integrationsanstrengung falsch ausrichtet, weil sie nach dem falschen Begriff sucht.
Hilft es, den Standardnamen getrennt von seinem Implementierungsnamen zu halten, die Architektur für die Personen zu klären, die sie tatsächlich bauen müssen – oder kostet es ihnen einfach Zeit herauszufinden, nach welchem Namen man zuerst suchen soll?
#dusk $DUSK @Dusk
XSC, Confidential Security Contract, ist der Name der Funktionalität – der Standard von Dusk, der für sicherheitsbezogene Use-Cases verwendet wird. Zedger ist das konkrete hybride Transaktionsmodell, das UTXO- und kontobasierte Elemente kombiniert, und das Dusk-eigene Materialien als das Modell nennen, das die XSC-Funktionalität bereitstellt. Das eine benennt, was das Netzwerk kann. Das andere ist der Mechanismus, der es ausführt. $DUSK
Ab hier hört das auf, nur theoretisch zu sein. Eine Institution, die sich mit Dusk für die Tokenisierung von Wertpapieren integriert, trifft keine Entscheidung zwischen „XSC“ und „Zedger“ als konkurrierende Optionen – sie baut gezielt gegen Zedger, während XSC der Compliance-Standardname ist, auf den ihre rechtliche und regulatorische Dokumentation Bezug nehmen wird. Die beiden zu verwechseln bedeutet, dass ein Entwickler möglicherweise nach „XSC-Integration-Dokumentation“ sucht und übersieht, dass die tatsächliche technische Implementierung vollständig unter dem Namen von Zedger läuft. #dusk
Der eigentliche Test für DUSK ist, ob diese Namensaufteilung jemals dazu führt, dass eine Institution eine Integrationsanstrengung falsch ausrichtet, weil sie nach dem falschen Begriff sucht.
Hilft es, den Standardnamen getrennt von seinem Implementierungsnamen zu halten, die Architektur für die Personen zu klären, die sie tatsächlich bauen müssen – oder kostet es ihnen einfach Zeit herauszufinden, nach welchem Namen man zuerst suchen soll?
#dusk $DUSK @Dusk