#dusk $DUSK @Dusk
Ich habe diese Woche Phoenix’ Notenstruktur durchgegangen, weil ich verstehen wollte, was „spent“ in einem UTXO-Privacy-Modell tatsächlich bedeutet — und die Antwort ist entgegen meiner Erwartung eher kontraintuitiv.
In einem transparenten UTXO-Modell wie Bitcoin gilt: Wenn du eine Coin ausgibst, weiß das Netzwerk genau, welches ungenutzte Output du verbraucht hast. Es entfernt diesen Output aus dem UTXO-Set. Die Kette kann nachvollziehen, was wohin gegangen ist.
Phoenix macht etwas anderes. Wenn du eine Note ausgibst, entfernt das Netzwerk sie nicht aus dem Merkle-Baum der Notes. Das Whitepaper ist ausdrücklich: „notes are not removed from the Merkle tree. Instead, the tree continues to grow as new transactions are added to the network.“
Was stattdessen passiert: Es wird eine Nullifier in eine separate Nullifier-Liste aufgenommen. Der Nullifier ist ein deterministischer Wert, der aus dem Secret Key der Note abgeleitet wird. Das Netzwerk prüft, dass dieser Nullifier noch nicht gesehen wurde — so wird Doppelausgabe verhindert. Aber das Netzwerk hat keine Möglichkeit, einen Nullifier wieder einer konkreten Note im Baum zuzuordnen. Es weiß nur, dass etwas ausgegeben wurde. Es weiß nicht, welche Note.
Dieser Teil ist stimmig. Die Unlinkability entsteht genau daraus, was das Netzwerk nicht lernt. Eine Note im Merkle-Baum sieht identisch aus, ob sie bereits ausgegeben wurde oder noch nicht. Ein Beobachter, der sich die Kette ansieht, kann nicht unterscheiden, ob es sich um eine frische ungenutzte Note handelt oder um eine Note, deren Nullifier bereits in der Liste steht.
. Im Laufe der Zeit, wenn die Nutzung von Phoenix steigt, wird der vollständige Merkle-Baum-Zustand für Nodes zu einer bedeutenden Speicherbelastung — all diese ausgegebenen Notes sitzen weiterhin dort, ununterscheidbar von den „lebenden“.
Ich glaube sogar, dass das eine bewusste Design-Abwägung ist und kein Versehen — das Entfernen ausgegebener Notes würde offenlegen, welche Notes ausgegeben wurden, und damit die Unlinkability zerstören. Aber es bedeutet, dass die Datenschutzgarantie echte Infrastrukturkosten verursacht, die mit der Nutzung skaliert.
Was ich noch nicht herausgefunden habe, ist, ob es einen Pruning-Mechanismus für sehr alte Notes gibt, die das Netzwerk als dauerhaft „spent“ akzeptiert hat — oder ob der Baum so konzipiert ist, dass er ohne jede Kompressionsstrategie unbegrenzt wächst.
Ich habe diese Woche Phoenix’ Notenstruktur durchgegangen, weil ich verstehen wollte, was „spent“ in einem UTXO-Privacy-Modell tatsächlich bedeutet — und die Antwort ist entgegen meiner Erwartung eher kontraintuitiv.
In einem transparenten UTXO-Modell wie Bitcoin gilt: Wenn du eine Coin ausgibst, weiß das Netzwerk genau, welches ungenutzte Output du verbraucht hast. Es entfernt diesen Output aus dem UTXO-Set. Die Kette kann nachvollziehen, was wohin gegangen ist.
Phoenix macht etwas anderes. Wenn du eine Note ausgibst, entfernt das Netzwerk sie nicht aus dem Merkle-Baum der Notes. Das Whitepaper ist ausdrücklich: „notes are not removed from the Merkle tree. Instead, the tree continues to grow as new transactions are added to the network.“
Was stattdessen passiert: Es wird eine Nullifier in eine separate Nullifier-Liste aufgenommen. Der Nullifier ist ein deterministischer Wert, der aus dem Secret Key der Note abgeleitet wird. Das Netzwerk prüft, dass dieser Nullifier noch nicht gesehen wurde — so wird Doppelausgabe verhindert. Aber das Netzwerk hat keine Möglichkeit, einen Nullifier wieder einer konkreten Note im Baum zuzuordnen. Es weiß nur, dass etwas ausgegeben wurde. Es weiß nicht, welche Note.
Dieser Teil ist stimmig. Die Unlinkability entsteht genau daraus, was das Netzwerk nicht lernt. Eine Note im Merkle-Baum sieht identisch aus, ob sie bereits ausgegeben wurde oder noch nicht. Ein Beobachter, der sich die Kette ansieht, kann nicht unterscheiden, ob es sich um eine frische ungenutzte Note handelt oder um eine Note, deren Nullifier bereits in der Liste steht.
. Im Laufe der Zeit, wenn die Nutzung von Phoenix steigt, wird der vollständige Merkle-Baum-Zustand für Nodes zu einer bedeutenden Speicherbelastung — all diese ausgegebenen Notes sitzen weiterhin dort, ununterscheidbar von den „lebenden“.
Ich glaube sogar, dass das eine bewusste Design-Abwägung ist und kein Versehen — das Entfernen ausgegebener Notes würde offenlegen, welche Notes ausgegeben wurden, und damit die Unlinkability zerstören. Aber es bedeutet, dass die Datenschutzgarantie echte Infrastrukturkosten verursacht, die mit der Nutzung skaliert.
Was ich noch nicht herausgefunden habe, ist, ob es einen Pruning-Mechanismus für sehr alte Notes gibt, die das Netzwerk als dauerhaft „spent“ akzeptiert hat — oder ob der Baum so konzipiert ist, dass er ohne jede Kompressionsstrategie unbegrenzt wächst.