Ich bin letzte Nacht noch einmal durch die Dokumentation zu den Transaktionsmodellen der @Dusk gegangen und habe ein paar Stunden damit verbracht, herauszufinden, wie Moonlight und Phoenix tatsächlich zusammenpassen.
Zunächst wirkte die Unterscheidung klar. Moonlight ist die transparente, konto-basierte Seite: Jedes Konto hält einen öffentlichen Zustand vor, der seinen Kontostand und Nonce aufzeichnet. Phoenix ist die notenbasierte, verschlüsselte Seite: Eine Note ist um einen Empfänger-öffentlichen Schlüssel, einen Wert v sowie zusätzliche zufällige Skalare strukturiert. Noten sind in einem Merkle-Baum indexiert, sodass ein Spender die Einbindung nachweisen kann, ohne die Note selbst offenzulegen. Fürs Ausgeben ist ein Zero-Knowledge-Beweis erforderlich und die Veröffentlichung eines Nullifiers, damit das Netzwerk Doppelausgaben zurückweisen kann. Die Doku nennt außerdem, dass Note-Werte durch 2^{64}-1 begrenzt sind.
Umwandlungspfade zwischen den beiden Modellen (Einzahlung in Phoenix-Noten, Rückzug zurück auf Moonlight-Konten) werden beschrieben, aber ich bin immer wieder an den exakten Sicherheitsannahmen hängen geblieben, die bei diesen Übergaben gelten. Die Circuits sollen Gültigkeit garantieren, doch ich konnte keine klare Aussage dazu finden, ob eine einzelne fehlerhafte Umwandlung den globalen Nullifier-Satz oder die transparenten Kontostände beeinflussen könnte, auf die Smart Contracts angewiesen sind.
Das hat für mich eine grundsätzliche Frage zur Dezentralisierung aufgeworfen: Wenn der Großteil des Werts letztlich in Phoenix-Noten lebt, wie viel praktische Governance-Macht bleibt dann bei der transparenten Kontoschicht, die Verträge und Orakel tatsächlich sehen?
Gilt das aktuelle Circuit-Design und die Wertegrenze 2^{64}-1 als endgültig, oder gibt es weiterhin offene Parameter rund um die Notenerzeugung, die Tiefe des Merkle-Baums und die Einzigartigkeit von Nullifiers, an denen die Community noch iteriert?
Würde mich über Hinweise von Leuten freuen, die tiefer in die Beweise eingestiegen sind.
#dusk $DUSK
Zunächst wirkte die Unterscheidung klar. Moonlight ist die transparente, konto-basierte Seite: Jedes Konto hält einen öffentlichen Zustand vor, der seinen Kontostand und Nonce aufzeichnet. Phoenix ist die notenbasierte, verschlüsselte Seite: Eine Note ist um einen Empfänger-öffentlichen Schlüssel, einen Wert v sowie zusätzliche zufällige Skalare strukturiert. Noten sind in einem Merkle-Baum indexiert, sodass ein Spender die Einbindung nachweisen kann, ohne die Note selbst offenzulegen. Fürs Ausgeben ist ein Zero-Knowledge-Beweis erforderlich und die Veröffentlichung eines Nullifiers, damit das Netzwerk Doppelausgaben zurückweisen kann. Die Doku nennt außerdem, dass Note-Werte durch 2^{64}-1 begrenzt sind.
Umwandlungspfade zwischen den beiden Modellen (Einzahlung in Phoenix-Noten, Rückzug zurück auf Moonlight-Konten) werden beschrieben, aber ich bin immer wieder an den exakten Sicherheitsannahmen hängen geblieben, die bei diesen Übergaben gelten. Die Circuits sollen Gültigkeit garantieren, doch ich konnte keine klare Aussage dazu finden, ob eine einzelne fehlerhafte Umwandlung den globalen Nullifier-Satz oder die transparenten Kontostände beeinflussen könnte, auf die Smart Contracts angewiesen sind.
Das hat für mich eine grundsätzliche Frage zur Dezentralisierung aufgeworfen: Wenn der Großteil des Werts letztlich in Phoenix-Noten lebt, wie viel praktische Governance-Macht bleibt dann bei der transparenten Kontoschicht, die Verträge und Orakel tatsächlich sehen?
Gilt das aktuelle Circuit-Design und die Wertegrenze 2^{64}-1 als endgültig, oder gibt es weiterhin offene Parameter rund um die Notenerzeugung, die Tiefe des Merkle-Baums und die Einzigartigkeit von Nullifiers, an denen die Community noch iteriert?
Würde mich über Hinweise von Leuten freuen, die tiefer in die Beweise eingestiegen sind.
#dusk $DUSK