Ich habe mir diese Tage noch einmal Phoenix’ Transaktionsstruktur genauer angesehen. Diesmal habe ich eine einzelne Transaktion einfach aufgesplittet, um herauszufinden, was man on-chain erkennen kann und was nicht.
━━━━━━━━━━━━━━
▎note: Was steckt in dem Eintrag?
Phoenix ist ein UTXO-Modell. Jede einzelne Einheit von Vermögenswerten heißt auf der Chain eine „note“. In so einer note werden drei Dinge verpackt: ein Commitment auf den Betrag (keine Klartext-Zahl, sondern ein verschlüsselter Commitment-Wert), ein blinding factor (vereinfacht: ein zufälliger Salt, der zum Commitment hinzugefügt wird, damit niemand durch Kollisionen auf den Betrag schließen kann) und eine einmalige Zufallszahl, die dafür sorgt, dass jede note eindeutig ist und nicht mit anderen notes kollidiert.
Diese drei Dinge zusammen bedeuten: On-chain sieht man im Grunde nur jede Menge verschlüsselte Daten. Wie viel konkret überwiesen wurde und wie viel diese note tatsächlich wert ist, kann ein Außenstehender nicht herausfinden. Das Netzwerk kann aber dennoch verifizieren, dass die Summe der Commitments für Ein- und Ausgänge ausbalanciert ist, ohne irgend eine konkrete Zahl zu entschlüsseln.
━━━━━━━━━━━━━━
▎Schutz vor Double-Spending durch nullifier
Das Design finde ich ziemlich genial: Es verhindert Double-Spending nicht dadurch, dass man „alte notes löscht“, sondern dadurch, dass man ein Konsumations-„Nachweis“-Token veröffentlicht, das sich nicht auf die ursprüngliche note zurückführen lässt.
Wenn man eine note ausgibt, wird ein dazugehöriger nullifier erzeugt. Dieses Ding wird deterministisch berechnet. Für Außenstehende ist es jedoch unmöglich, daraus direkt abzuleiten, zu welcher note es gehört. Das Netzwerk muss nur darauf achten: „Ist dieser nullifier schon einmal aufgetaucht?“ Wenn ja, dann heißt das, dass die dazugehörige note bereits ausgegeben wurde. Wenn man versucht, dieselbe note ein zweites Mal auszugeben, wird derselbe nullifier erneut erzeugt – und prallt direkt mit dem bereits vorhandenen Eintrag zusammen. Das System lehnt die Transaktion sofort ab.
Im gesamten Prozess wird nicht offengelegt, „wer etwas tut“ oder „was genau ausgegeben wird“ – alles wird über Kollisionsprüfungen geregelt.
━━━━━━━━━━━━━━
▎Poseidon-Hash: Das Fundament für den gesamten Privacy-Status
Der Privacy-Status muss in einem Merkle-Baum gespeichert werden. Dafür nutzt man Beweise für die Zugehörigkeit von Mitgliedern (also den Nachweis: „Diese note existiert tatsächlich im Statusbaum“).
Wenn man eine normale Hash-Funktion in einen zk-Schaltkreis einbaut, ist der Aufwand enorm. Poseidon ist eine Hash-Funktion, die speziell für zk-freundliche Systeme entwickelt wurde. Ihr Aufbau passt besser zum Beweissystem, wodurch die Kosten für Hash-Berechnungen in den Schaltkreisen deutlich sinken. Ohne so einen zk-freundlichen Hash wäre die Generierung der Beweise für den Privacy-Statusbaum so langsam, dass sie praktisch nicht nutzbar wäre.
@Dusk_Foundation $DUSK #dusk
In einer Phoenix-Transaktion: Welche Mechanismen verhindern, dass versteckte Assets doppelt ausgegeben werden?