#dusk $DUSK @Dusk Ich habe fast vierzig Minuten lang Dokumente zu Dusk gelesen und dabei immer wieder dieselbe Frage im Kopf gehabt: Wie geht das zwischen Moonlight und Phoenix eigentlich am Ende aus?
Moonlight geht den Weg über öffentliche Konten. Kontostand, Absender der Überweisung, Empfänger und der Betrag stehen allesamt auf der Chain – für alle sichtbar. Das eignet sich für Szenarien, in denen Transparenz zwingend ist, etwa Börsen-Top-ups oder die Abgleicharbeit von Institutionen.
Phoenix ist dagegen ein ganz anderes Konzept: Vermögenswerte werden zu verschlüsselten notes und in einem Merkle-Baum versteckt. Wenn du eine Zahlung ausgibst, wird nicht offengelegt, welche konkrete note du verwendest. Stattdessen wirfst du einen Nullifier plus einen ZKP-Beweis ins Netz. Das Netzwerk kann verifizieren, dass du Geld hast und keine Double-Spends machst, aber es sieht weder den Betrag noch den Absender. Wenn ein Audit nötig ist, kann man über einen Viewing Key selektiv Informationen offenlegen.
Anfang des Monats bin ich beim Schreiben meiner Notizen zu SEPA-Überweisungen auf ein ähnliches Problem gestoßen: Zwischen zwei Bankensystemen abgleichen, und wenn der Status nicht übereinstimmt, ist das unglaublich nervig – ich wurde damals bis nach zwei Uhr nachts damit herumgehetzt. Wenn die Blockchain dann auch noch zwei getrennte, isolierte Ledger führt, wäre das im Grunde nicht besser als das klassische Finanzwesen.
Damals war ich ein bisschen genervt, weil in den Dokumenten zu diesem Thema nicht klar genug erklärt wurde, was genau gemeint ist. Ich bin dann zum Abschnitt über die Vertragsarchitektur im Rusk-Modul geblättert. Die ersten beiden Absätze wirkten zunächst nicht besonders aufschlussreich – im Grunde nur Beschreibungen der jeweiligen Datenstrukturen von Moonlight und Phoenix. Erst als ich zum vierten Absatz kam und im Interface-Definition der Transfer-Contract-Schnittstelle auf einen Enum-Typ für das Payload gestoßen bin, wurde mir der Designgedanke richtig klar.
Der Transfer Contract ist so ein Koordinations-Einstiegspunkt. Er nimmt Payloads in unterschiedlichen Formaten entgegen – einerseits in Moonlight-Format, andererseits in Phoenix-Format. Der Smart Contract interessiert sich nicht dafür, woher du kommst; er kümmert sich nur darum, welche Felder im Payload enthalten sind, und routet das dann in die jeweils passende Verifikationslogik. Die Verifikation für Moonlight liest direkt den Zustand des öffentlichen Kontos, die für Phoenix läuft über den ZK-Proof. Wenn beide Verifikationen erfolgreich sind, schreibt man das Ergebnis in denselben globalen Zustand-Baum.
Ich habe eine Weile gebraucht, um den entscheidenden Punkt dieser letzten Stufe zu begreifen: Wenn du die beiden Zustandsbäume zu einer einzigen Struktur zusammenführst, dann ist das „Umschreiben“ von einem öffentlichen Konto hin zu einer privaten note im Kern nur eine Umwandlung des Payloads – ohne Cross-Chain-Bridge und ohne komplexes Synchronisationsprotokoll. Die Statusaktualisierung ist atomar: Entweder klappt alles vollständig, oder es wird alles zurückgerollt.
Moonlight geht den Weg über öffentliche Konten. Kontostand, Absender der Überweisung, Empfänger und der Betrag stehen allesamt auf der Chain – für alle sichtbar. Das eignet sich für Szenarien, in denen Transparenz zwingend ist, etwa Börsen-Top-ups oder die Abgleicharbeit von Institutionen.
Phoenix ist dagegen ein ganz anderes Konzept: Vermögenswerte werden zu verschlüsselten notes und in einem Merkle-Baum versteckt. Wenn du eine Zahlung ausgibst, wird nicht offengelegt, welche konkrete note du verwendest. Stattdessen wirfst du einen Nullifier plus einen ZKP-Beweis ins Netz. Das Netzwerk kann verifizieren, dass du Geld hast und keine Double-Spends machst, aber es sieht weder den Betrag noch den Absender. Wenn ein Audit nötig ist, kann man über einen Viewing Key selektiv Informationen offenlegen.
Anfang des Monats bin ich beim Schreiben meiner Notizen zu SEPA-Überweisungen auf ein ähnliches Problem gestoßen: Zwischen zwei Bankensystemen abgleichen, und wenn der Status nicht übereinstimmt, ist das unglaublich nervig – ich wurde damals bis nach zwei Uhr nachts damit herumgehetzt. Wenn die Blockchain dann auch noch zwei getrennte, isolierte Ledger führt, wäre das im Grunde nicht besser als das klassische Finanzwesen.
Damals war ich ein bisschen genervt, weil in den Dokumenten zu diesem Thema nicht klar genug erklärt wurde, was genau gemeint ist. Ich bin dann zum Abschnitt über die Vertragsarchitektur im Rusk-Modul geblättert. Die ersten beiden Absätze wirkten zunächst nicht besonders aufschlussreich – im Grunde nur Beschreibungen der jeweiligen Datenstrukturen von Moonlight und Phoenix. Erst als ich zum vierten Absatz kam und im Interface-Definition der Transfer-Contract-Schnittstelle auf einen Enum-Typ für das Payload gestoßen bin, wurde mir der Designgedanke richtig klar.
Der Transfer Contract ist so ein Koordinations-Einstiegspunkt. Er nimmt Payloads in unterschiedlichen Formaten entgegen – einerseits in Moonlight-Format, andererseits in Phoenix-Format. Der Smart Contract interessiert sich nicht dafür, woher du kommst; er kümmert sich nur darum, welche Felder im Payload enthalten sind, und routet das dann in die jeweils passende Verifikationslogik. Die Verifikation für Moonlight liest direkt den Zustand des öffentlichen Kontos, die für Phoenix läuft über den ZK-Proof. Wenn beide Verifikationen erfolgreich sind, schreibt man das Ergebnis in denselben globalen Zustand-Baum.
Ich habe eine Weile gebraucht, um den entscheidenden Punkt dieser letzten Stufe zu begreifen: Wenn du die beiden Zustandsbäume zu einer einzigen Struktur zusammenführst, dann ist das „Umschreiben“ von einem öffentlichen Konto hin zu einer privaten note im Kern nur eine Umwandlung des Payloads – ohne Cross-Chain-Bridge und ohne komplexes Synchronisationsprotokoll. Die Statusaktualisierung ist atomar: Entweder klappt alles vollständig, oder es wird alles zurückgerollt.
