#dusk $DUSK @Dusk Diese Woche habe ich die Arbeit von Dusk zum Phoenix-Transaktionsmodell (in der es in der Citadel-Arbeit speziell einen Abschnitt zu Phoenix gibt) einmal komplett durchgearbeitet. Zuvor hatte ich immer gedacht, dass es sich bei Phoenix nicht wirklich grundlegend von anderen UTXO-Privacy-Ansätzen unterscheidet – aber nach der Lektüre merkt man, dass die Detailgestaltung deutlich ausgeklügelter ist, als man zunächst vermutet.
In Phoenix heißt jede einzelne „Asset“-Transaktion nicht UTXO, sondern note. Das Netzwerk speichert die note selbst nicht direkt, sondern legt nur den Hashwert der note als Blatt in einem Merkle-Baum ab. Wenn eine note ausgegeben („spent“) wird, muss der Nutzer einen sogenannten tx_proof-Zero-Knowledge-Beweis einreichen. Dieser Beweis erledigt gleichzeitig zwei Dinge: Erstens „macht“ er die note, die ausgegeben werden soll, ungültig (erzeugt einen eindeutigen nullifier, damit dasselbe Geld nicht zweimal ausgegeben werden kann). Zweitens beweist er, dass die Summe der neu erzeugten notes mit der Summe der ungültig gemachten notes übereinstimmt und dass dabei kein Geld „aus dem Nichts“ geprägt wird. Von außen ist währenddessen nur zu sehen: „eine alte note wird ungültig gemacht“ und „eine neue note wird erstellt“. Die konkreten Beträge und die beteiligten Parteien sind nach außen nicht einsehbar.
Was mich besonders überzeugt, ist die Schlüsselaufteilung: Zum Ausgeben einer note braucht man einen Secret Key, den nur der Besitzer der note selbst kennt. Wenn man jedoch nur möchte, dass ein Prüfer oder ein Regulator sieht, welche notes man hat und welche (verschlüsselten) Beträge in ihnen stecken, muss man nicht die Ausgaberechte preisgeben. Stattdessen kann man den View Key separat teilen. Das heißt: „sehen können“ und „ausgeben können“ sind zwei vollständig unabhängige Schlüssel. Diese Auftrennung ist damit eine kryptografische Grundlage für das Konzept der „selektiven Offenlegung“ – nicht nur leeres Marketing-Vokabular.
Zusätzlich gibt es noch einen leicht zu übersehenden Detailpunkt im Transfer-Contract: Er führt proaktiv ein Zusammenführen (combine) mehrerer kleiner notes durch, um zu verhindern, dass die Blattknoten des Merkle-Baums unendlich anwachsen und dadurch die Netzwerkleistung ausbremsen. Dieses Design, bei dem das „unterliegende Ledger“ quasi selbst Garbage Collection betreibt, zeigt, dass das Team schon in der frühen Phase vorausschauend Ingenieurarbeit für die langfristig entstehenden Speicher- und Proof-Kosten gemacht hat – statt erst zu reagieren, wenn der Baum zu groß geworden ist, um noch vernünftig zu laufen.
Für Entwickler bedeutet diese Mechanik: Wenn du auf Phoenix eine Anwendung aufbauen willst, wird die Verteilung und Verwaltung des View Keys zu einem nicht wegzudenkenden Produktdesign-Problem. Denn davon hängt ab, wer unter welchen Bedingungen die Bestände des Nutzers sehen kann. Wenn dieser Schritt nicht sauber designt ist, ist „Privacy“ am Ende nur noch ein Schalter in der Wallet-UI – ohne echte, belastbare Wirkung.
In Phoenix heißt jede einzelne „Asset“-Transaktion nicht UTXO, sondern note. Das Netzwerk speichert die note selbst nicht direkt, sondern legt nur den Hashwert der note als Blatt in einem Merkle-Baum ab. Wenn eine note ausgegeben („spent“) wird, muss der Nutzer einen sogenannten tx_proof-Zero-Knowledge-Beweis einreichen. Dieser Beweis erledigt gleichzeitig zwei Dinge: Erstens „macht“ er die note, die ausgegeben werden soll, ungültig (erzeugt einen eindeutigen nullifier, damit dasselbe Geld nicht zweimal ausgegeben werden kann). Zweitens beweist er, dass die Summe der neu erzeugten notes mit der Summe der ungültig gemachten notes übereinstimmt und dass dabei kein Geld „aus dem Nichts“ geprägt wird. Von außen ist währenddessen nur zu sehen: „eine alte note wird ungültig gemacht“ und „eine neue note wird erstellt“. Die konkreten Beträge und die beteiligten Parteien sind nach außen nicht einsehbar.
Was mich besonders überzeugt, ist die Schlüsselaufteilung: Zum Ausgeben einer note braucht man einen Secret Key, den nur der Besitzer der note selbst kennt. Wenn man jedoch nur möchte, dass ein Prüfer oder ein Regulator sieht, welche notes man hat und welche (verschlüsselten) Beträge in ihnen stecken, muss man nicht die Ausgaberechte preisgeben. Stattdessen kann man den View Key separat teilen. Das heißt: „sehen können“ und „ausgeben können“ sind zwei vollständig unabhängige Schlüssel. Diese Auftrennung ist damit eine kryptografische Grundlage für das Konzept der „selektiven Offenlegung“ – nicht nur leeres Marketing-Vokabular.
Zusätzlich gibt es noch einen leicht zu übersehenden Detailpunkt im Transfer-Contract: Er führt proaktiv ein Zusammenführen (combine) mehrerer kleiner notes durch, um zu verhindern, dass die Blattknoten des Merkle-Baums unendlich anwachsen und dadurch die Netzwerkleistung ausbremsen. Dieses Design, bei dem das „unterliegende Ledger“ quasi selbst Garbage Collection betreibt, zeigt, dass das Team schon in der frühen Phase vorausschauend Ingenieurarbeit für die langfristig entstehenden Speicher- und Proof-Kosten gemacht hat – statt erst zu reagieren, wenn der Baum zu groß geworden ist, um noch vernünftig zu laufen.
Für Entwickler bedeutet diese Mechanik: Wenn du auf Phoenix eine Anwendung aufbauen willst, wird die Verteilung und Verwaltung des View Keys zu einem nicht wegzudenkenden Produktdesign-Problem. Denn davon hängt ab, wer unter welchen Bedingungen die Bestände des Nutzers sehen kann. Wenn dieser Schritt nicht sauber designt ist, ist „Privacy“ am Ende nur noch ein Schalter in der Wallet-UI – ohne echte, belastbare Wirkung.