Zwei strukturell unterschiedliche Transaktionsmodelle auf einer einzigen Settlement-Ebene zu betreiben, ist in der Theorie eine Sache. Tatsächlich sicherzustellen, dass sie sich nicht widersprechen können, ist ein ganz anderes Problem – und DuskDS löst es mit einem ganz bestimmten Architekturbaustein: dem Transfer Contract.
Phoenix und Moonlight sind keine unabhängigen Systeme, die parallel laufen und darauf hoffen, zufällig konsistent zu bleiben. Jede Wertbewegung – ob eine abgeschirmte UTXO-Note unter Phoenix oder ein öffentliches Kontoguthaben unter Moonlight – läuft letztlich durch den Transfer Contract, der auf DuskDS tatsächlich über den globalen Zustand bestimmt. Er ist die einzige Instanz, die dafür verantwortlich ist, sicherzustellen, dass das Ausgeben einer abgeschirmten Note und das Aktualisieren eines öffentlichen Guthabens niemals zu einer inkonsistenten Gesamtsumme führen, niemals Wert aus dem Nichts erzeugen und die beiden Modelle im Laufe der Zeit nicht auseinanderdriften lassen.
Konkret bedeutet das: Phoenix und Moonlight sind keine zwei separaten Ledger, die zufällig dieselbe Chain nutzen. Sie sind zwei unterschiedliche Darstellungen, deren Konsistenz durch eine gemeinsame Wahrheitsquelle gewährleistet wird. Das Datenschutzmodell ändert sich je nach verwendetem Transaktionstyp, aber die zugrunde liegende Buchführung darf sich nicht widersprechen – je nachdem, von welcher Seite des Systems aus man sie betrachtet.
Dieser Teil des Designs muss makellos sein, damit der gesamte Dual-Model-Ansatz von vor ein paar Tagen auch im realen Einsatz standhält. Wenn der Transfer Contract bei der Abstimmung der beiden Modelle irgendeine Inkonsistenz aufwiese, wäre das kein kleiner Fehler, sondern eine Stelle, an der theoretisch Wert geschaffen werden oder verloren gehen könnte – allein dadurch, dass man zwischen einer abgeschirmten und einer transparenten Darstellung desselben Assets wechselt.
Ist es also das sicherere Design, diese Abstimmung in einem einzigen Contract zu zentralisieren, weil es dann genau eine Stelle gibt, an der man die Korrektheit prüfen und verifizieren kann? Oder konzentriert eine derart große Verantwortung in einem einzelnen Contract lediglich das Risiko, statt es tatsächlich zu verringern?
#dusk @Dusk $DUSK
Phoenix und Moonlight sind keine unabhängigen Systeme, die parallel laufen und darauf hoffen, zufällig konsistent zu bleiben. Jede Wertbewegung – ob eine abgeschirmte UTXO-Note unter Phoenix oder ein öffentliches Kontoguthaben unter Moonlight – läuft letztlich durch den Transfer Contract, der auf DuskDS tatsächlich über den globalen Zustand bestimmt. Er ist die einzige Instanz, die dafür verantwortlich ist, sicherzustellen, dass das Ausgeben einer abgeschirmten Note und das Aktualisieren eines öffentlichen Guthabens niemals zu einer inkonsistenten Gesamtsumme führen, niemals Wert aus dem Nichts erzeugen und die beiden Modelle im Laufe der Zeit nicht auseinanderdriften lassen.
Konkret bedeutet das: Phoenix und Moonlight sind keine zwei separaten Ledger, die zufällig dieselbe Chain nutzen. Sie sind zwei unterschiedliche Darstellungen, deren Konsistenz durch eine gemeinsame Wahrheitsquelle gewährleistet wird. Das Datenschutzmodell ändert sich je nach verwendetem Transaktionstyp, aber die zugrunde liegende Buchführung darf sich nicht widersprechen – je nachdem, von welcher Seite des Systems aus man sie betrachtet.
Dieser Teil des Designs muss makellos sein, damit der gesamte Dual-Model-Ansatz von vor ein paar Tagen auch im realen Einsatz standhält. Wenn der Transfer Contract bei der Abstimmung der beiden Modelle irgendeine Inkonsistenz aufwiese, wäre das kein kleiner Fehler, sondern eine Stelle, an der theoretisch Wert geschaffen werden oder verloren gehen könnte – allein dadurch, dass man zwischen einer abgeschirmten und einer transparenten Darstellung desselben Assets wechselt.
Ist es also das sicherere Design, diese Abstimmung in einem einzigen Contract zu zentralisieren, weil es dann genau eine Stelle gibt, an der man die Korrektheit prüfen und verifizieren kann? Oder konzentriert eine derart große Verantwortung in einem einzelnen Contract lediglich das Risiko, statt es tatsächlich zu verringern?
#dusk @Dusk $DUSK