Die Details zum Phoenix-Manöver sind leicht zu übersehen:
Ausgegebene Hinweise bleiben im Merkle-Baum.
Ich behandelte diesen Baum anfangs wie einen privaten UTXO-Satz. Wenn ein Hinweis ausgegeben wurde, nahm ich an, er würde verschwinden.
Das Whitepaper sagt etwas anderes.
Wenn ein Phoenix-Hinweis ausgegeben wird, leitet sein Besitzer einen Nullifier aus dem Geheimen Schlüssel des Hinweises ab. Das Netzwerk protokolliert diesen Nullifier, sodass der Hinweis nicht erneut ausgegeben werden kann.
Aber es lernt nicht, zu welchem Hinweis der Nullifier gehört.
Also bleibt der Hinweis. Der Baum wächst weiter.
Das schafft eine Unterscheidung, an die ich nicht gedacht hatte:
protokolliert ist nicht dasselbe wie ausgabefähig.
Ein aktueller Merkle-Root ermöglicht es dem Netzwerk zu verifizieren, dass ein Eingabe-Hinweis zum Baum gehört. Die reine Mitgliedschaft bedeutet nicht, dass der Wert noch „lebendig“ ist.
Diese Antwort steckt in der Nullifier-Liste.
Und Phoenix hält die öffentliche Verknüpfung zwischen beiden verdeckt.
In Moonlight ordnet Dusk ein Konto einem öffentlichen Kontostand zu.
Phoenix funktioniert anders. Das Netzwerk verifiziert einen ZK-Beweis, dass Eingabe-Hinweise korrekt nullifiziert sind und genug Wert für neue Hinweise, Einzahlung und den maximalen Gasverbrauch besitzen, ohne die Beträge offenzulegen.
So kann ein Phoenix-Hinweis weiterhin protokolliert bleiben, obwohl sein ökonomischer Nutzen bereits verschwunden ist.
Der Datensatz überlebt.
Das Ausgaberecht nicht.
Dann gibt es noch eine weitere Trennung.
Ein View Key kann an eine vertrauenswürdige Partei gegeben werden, damit sie das Netzwerk durchsucht und Transaktionen identifiziert, die an den Benutzer adressiert sind. Aber sie kann diese Hinweise trotzdem nicht ausgeben, weil der Geheimschlüssel des Hinweises den gesamten Geheimschlüssel des Nutzers erfordert.
Daher sind „kann meinen privaten Zustand sehen“ und „kann meinen privaten Zustand kontrollieren“ unterschiedliche Berechtigungen.
Es zeigen sich zwei Grenzen:
protokolliert / ausgabefähig
sichtbar / kontrollierbar
Der Sonderfall, zu dem ich immer wieder zurückkomme, ist eine Anwendung, die rekonstruiert, was ein Nutzer gerade hat.
Dass der Hinweis vorhanden ist, reicht nicht aus.
Ihn erkennen zu können, reicht ebenfalls nicht.
Du brauchst Historie, den Nullifikationszustand und das richtige geheime Material.
Das lässt mich dann fragen:
In einem privaten Ledger—ist „aktueller Zustand“ überhaupt ein einzelnes Objekt, oder ist er die Schnittmenge von Aufzeichnungen, die beim Lesen allein absichtlich unvollständig sind?
@Dusk #dusk $DUSK $VELVET $APR
Ausgegebene Hinweise bleiben im Merkle-Baum.
Ich behandelte diesen Baum anfangs wie einen privaten UTXO-Satz. Wenn ein Hinweis ausgegeben wurde, nahm ich an, er würde verschwinden.
Das Whitepaper sagt etwas anderes.
Wenn ein Phoenix-Hinweis ausgegeben wird, leitet sein Besitzer einen Nullifier aus dem Geheimen Schlüssel des Hinweises ab. Das Netzwerk protokolliert diesen Nullifier, sodass der Hinweis nicht erneut ausgegeben werden kann.
Aber es lernt nicht, zu welchem Hinweis der Nullifier gehört.
Also bleibt der Hinweis. Der Baum wächst weiter.
Das schafft eine Unterscheidung, an die ich nicht gedacht hatte:
protokolliert ist nicht dasselbe wie ausgabefähig.
Ein aktueller Merkle-Root ermöglicht es dem Netzwerk zu verifizieren, dass ein Eingabe-Hinweis zum Baum gehört. Die reine Mitgliedschaft bedeutet nicht, dass der Wert noch „lebendig“ ist.
Diese Antwort steckt in der Nullifier-Liste.
Und Phoenix hält die öffentliche Verknüpfung zwischen beiden verdeckt.
In Moonlight ordnet Dusk ein Konto einem öffentlichen Kontostand zu.
Phoenix funktioniert anders. Das Netzwerk verifiziert einen ZK-Beweis, dass Eingabe-Hinweise korrekt nullifiziert sind und genug Wert für neue Hinweise, Einzahlung und den maximalen Gasverbrauch besitzen, ohne die Beträge offenzulegen.
So kann ein Phoenix-Hinweis weiterhin protokolliert bleiben, obwohl sein ökonomischer Nutzen bereits verschwunden ist.
Der Datensatz überlebt.
Das Ausgaberecht nicht.
Dann gibt es noch eine weitere Trennung.
Ein View Key kann an eine vertrauenswürdige Partei gegeben werden, damit sie das Netzwerk durchsucht und Transaktionen identifiziert, die an den Benutzer adressiert sind. Aber sie kann diese Hinweise trotzdem nicht ausgeben, weil der Geheimschlüssel des Hinweises den gesamten Geheimschlüssel des Nutzers erfordert.
Daher sind „kann meinen privaten Zustand sehen“ und „kann meinen privaten Zustand kontrollieren“ unterschiedliche Berechtigungen.
Es zeigen sich zwei Grenzen:
protokolliert / ausgabefähig
sichtbar / kontrollierbar
Der Sonderfall, zu dem ich immer wieder zurückkomme, ist eine Anwendung, die rekonstruiert, was ein Nutzer gerade hat.
Dass der Hinweis vorhanden ist, reicht nicht aus.
Ihn erkennen zu können, reicht ebenfalls nicht.
Du brauchst Historie, den Nullifikationszustand und das richtige geheime Material.
Das lässt mich dann fragen:
In einem privaten Ledger—ist „aktueller Zustand“ überhaupt ein einzelnes Objekt, oder ist er die Schnittmenge von Aufzeichnungen, die beim Lesen allein absichtlich unvollständig sind?
@Dusk #dusk $DUSK $VELVET $APR